From lthon at redhat.com Mon Dec 1 04:43:10 2014 From: lthon at redhat.com (Ladislav Thon) Date: Mon, 01 Dec 2014 10:43:10 +0100 Subject: [wildfly-dev] IMPORTANT: First overview of changes to jboss-ejb-client 3.0 for WildFly 10 (probably) In-Reply-To: <54789C07.7010309@redhat.com> References: <547621FB.3050107@redhat.com> <54788DB5.3040001@redhat.com> <54789C07.7010309@redhat.com> Message-ID: <547C382E.80104@redhat.com> Inline. >>> ? The following classes and interfaces are currently removed in my >>> working copy: >>> ? ClusterContext - replaced with discovery (?) >>> ? ClusterNodeManager - replaced with discovery >>> >>> ? ClusterNodeSelector - replaced with discovery >>> ? DeploymentNodeSelector - replaced with discovery >> As Cluster/Deployment NodeSelector is being removed and replaced by >> discovery this sounds to me that there is no possibility to customize >> the load-balancing process >> >> This might affect some use-cases where such policy was implemented to >> control specific behaviour. > > This is an example of an API that can probably be added back. I want to > spend some time consulting with Radoslav H. and Paul F. though to make > sure that the API is "right" before I reintroduce this exact API (or a > similar one). Any input regarding use cases will be useful, I expect. I'm using {Cluster,Deployment}NodeSelectors in some tests to make sure that a remote invocation ends up on a well-known cluster node. Specifically, the tests are asserting certain behavior of EJB client failover in case a server fails while the invocation is in progress. I'm not insisting on these particular interfaces, what's important for me is the ability to make the target node selection predictable. LT From tomaz.cerar at gmail.com Mon Dec 1 06:34:37 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 1 Dec 2014 12:34:37 +0100 Subject: [wildfly-dev] Jigsaw early-access builds updated (JDK 9 build 40) In-Reply-To: <5478BF02.70406@oracle.com> References: <54733D0A.4090709@oracle.com> <5478BF02.70406@oracle.com> Message-ID: Hey Rory, I setup CI job to run with jdk9 b40. you can see it here http://teamcity.cafe-babe.org/viewType.html?buildTypeId=WildFly_WildflyCore_Build (login as guest to access it) it runs from my jdk9 branch https://github.com/ctomc/wildfly-core/tree/jdk9 that has two commits to get rid of PremGen in build / testsuite and some small changes around our direct jconsole.jar usages. i will set similar thing for wildfly "full" repository, as currently it doesn't even build becouse of PremGen params we use for building / testing code. job can be found here http://teamcity.cafe-babe.org/viewType.html?buildTypeId=WildFly_LinuxJdk9 -- tomaz On Fri, Nov 28, 2014 at 7:29 PM, Rory O'Donnell wrote: > Hi Jason/Tomaz, > > We have had a report internally that Jigsaw in JDK 9 Build 36 seems to > work with WildFly, while there > are issues with b40. The details are sketchy at the moment, is it possible > to check this out and let us > know ? > > Rgds,Rory > > On 24/11/2014 14:13, Rory O'Donnell wrote: > > > Hi Jason/Tomaz, > > JDK 9 Early Access with Project Jigsaw build b40 is available for download > at : > https://jdk9.java.net/jigsaw/ > > The goal of Project Jigsaw [2] is to design and implement a standard > module > system for the Java SE Platform, and to apply that system to the Platform > itself > and to the JDK. > > The main change in this build is that it includes the jrt: file-system > provider, > so it now implements all of the changes described in JEP 220. > > Please refer to Project Jigsaw's updated project pages [2] & [4] and Mark > Reinhold's update [5] for further details. > > We are very interested in your experiences testing this build. Comments, > questions, and suggestions are welcome on the jigsaw-dev > mailing list > or > through bug reports via bugs.java.com. > > Note: If you haven?t already subscribed to that mailing list then please > do > so first, otherwise your message will be discarded as spam. > > Rgds, Rory > > [1] https://jdk9.java.net/jigsaw/ > [2] http://openjdk.java.net/projects/jigsaw/ > [3] http://openjdk.java.net/jeps/220 > [4] http://openjdk.java.net/projects/jigsaw/ea > [5] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/004014.html > > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > -- > 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/20141201/9150a41b/attachment-0001.html From rory.odonnell at oracle.com Mon Dec 1 07:03:27 2014 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 01 Dec 2014 12:03:27 +0000 Subject: [wildfly-dev] Jigsaw early-access builds updated (JDK 9 build 40) In-Reply-To: References: <54733D0A.4090709@oracle.com> <5478BF02.70406@oracle.com> Message-ID: <547C590F.7070900@oracle.com> On 01/12/2014 11:34, Toma? Cerar wrote: > Hey Rory, > > I setup CI job to run with jdk9 b40. you can see it here > http://teamcity.cafe-babe.org/viewType.html?buildTypeId=WildFly_WildflyCore_Build > (login as guest to access it) Hi Tomaz, is this jdk9-b40 or the jigsaw/m2? The jigsaw Early access builds are available here Many Thanks,Rory > > it runs from my jdk9 branch > https://github.com/ctomc/wildfly-core/tree/jdk9 that has two commits > to get rid of PremGen in build / testsuite and some small changes > around our direct jconsole.jar usages. > i will set similar thing for wildfly "full" repository, as currently > it doesn't even build becouse of PremGen params we use for building / > testing code. > job can be found here > http://teamcity.cafe-babe.org/viewType.html?buildTypeId=WildFly_LinuxJdk9 > > -- > tomaz > > > On Fri, Nov 28, 2014 at 7:29 PM, Rory O'Donnell > > wrote: > > Hi Jason/Tomaz, > > We have had a report internally that Jigsaw in JDK 9 Build 36 > seems to work with WildFly, while there > are issues with b40. The details are sketchy at the moment, is it > possible to check this out and let us > know ? > > Rgds,Rory > > On 24/11/2014 14:13, Rory O'Donnell wrote: >> >> Hi Jason/Tomaz, >> >> JDK 9 Early Access with Project Jigsaw build b40 is available for >> download at : >> https://jdk9.java.net/jigsaw/ >> >> The goal of Project Jigsaw [2] is to design and implement a >> standard module >> system for the Java SE Platform, and to apply that system to the >> Platform itself >> and to the JDK. >> >> The main change in this build is that it includes the jrt: >> file-system provider, >> so it now implements all of the changes described in JEP 220. >> >> Please refer to Project Jigsaw's updated project pages [2] & [4] >> and Mark >> Reinhold's update [5] for further details. >> >> We are very interested in your experiences testing this build. >> Comments, >> questions, and suggestions are welcome on the jigsaw-dev >> >> mailing list or >> through bug reports via bugs.java.com . >> >> Note: If you haven?t already subscribed to that mailing list then >> please do >> so first, otherwise your message will be discarded as spam. >> >> Rgds, Rory >> >> [1] https://jdk9.java.net/jigsaw/ >> [2] http://openjdk.java.net/projects/jigsaw/ >> [3] http://openjdk.java.net/jeps/220 >> [4] http://openjdk.java.net/projects/jigsaw/ea >> [5] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/004014.html >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -- 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/20141201/b6c20f00/attachment.html From tomaz.cerar at gmail.com Mon Dec 1 07:23:37 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 1 Dec 2014 13:23:37 +0100 Subject: [wildfly-dev] Jigsaw early-access builds updated (JDK 9 build 40) In-Reply-To: <547C590F.7070900@oracle.com> References: <54733D0A.4090709@oracle.com> <5478BF02.70406@oracle.com> <547C590F.7070900@oracle.com> Message-ID: On Mon, Dec 1, 2014 at 1:03 PM, Rory O'Donnell wrote: > is this jdk9-b40 or the jigsaw/m2? Yes this is jigsaw build, concretely this is the file I downloaded jigsaw-jdk-9-ea-bin-b40-linux-i586-17_nov_2014.tar.gz -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141201/1d8fcd1a/attachment.html From rory.odonnell at oracle.com Mon Dec 1 07:33:44 2014 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 01 Dec 2014 12:33:44 +0000 Subject: [wildfly-dev] Jigsaw early-access builds updated (JDK 9 build 40) In-Reply-To: References: <54733D0A.4090709@oracle.com> <5478BF02.70406@oracle.com> <547C590F.7070900@oracle.com> Message-ID: <547C6028.2040504@oracle.com> Many thanks for confirming Tomaz! On 01/12/2014 12:23, Toma? Cerar wrote: > > On Mon, Dec 1, 2014 at 1:03 PM, Rory O'Donnell > > wrote: > > is this jdk9-b40 or the jigsaw/m2? > > > > Yes this is jigsaw build, concretely this is the file I downloaded > jigsaw-jdk-9-ea-bin-b40-linux-i586-17_nov_2014.tar.gz > > -- > tomaz -- 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/20141201/82a467e0/attachment.html From tdiesler at redhat.com Tue Dec 2 02:49:02 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Tue, 2 Dec 2014 08:49:02 +0100 Subject: [wildfly-dev] Camel subsystem on WildFly Message-ID: Folks, I?m happy to announce the availability of the Camel subsystem for WildFly. The WildFly-Camel Subsystem allows you to add Camel Routes as part of the WildFly configuration. Routes can be deployed as part of JavaEE applications. JavaEE components can access the Camel Core API and various Camel Component APIs. Your Enterprise Integration Solution can be architected as a combination of JavaEE and Camel functionality. We added a number of new camel components to the subsystem and added support for the WildFly domain mode. A new set of standalone examples shows how to use Camel in the context of JavaEE applications. Ready available docker images are published as wildflyext/wildfly-camel . For details, please have a look at the release notes . cheers ?thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141202/c434b3e0/attachment.html From kirigakavin at gmail.com Tue Dec 2 04:19:02 2014 From: kirigakavin at gmail.com (Calvin Ngotho) Date: Tue, 2 Dec 2014 12:19:02 +0300 Subject: [wildfly-dev] Camel subsystem on WildFly In-Reply-To: References: Message-ID: This is great !!! On Dec 2, 2014 10:49 AM, "Thomas Diesler" wrote: > Folks, > > I?m happy to announce the availability of the Camel subsystem for WildFly. > > The WildFly-Camel Subsystem allows you to add Camel Routes as part of the > WildFly configuration. > Routes can be deployed as part of JavaEE applications. JavaEE components > can access the Camel Core API and various Camel Component APIs. > Your Enterprise Integration Solution can be architected as a combination > of JavaEE and Camel functionality. > > We added a number of new camel components > to > the subsystem and added support for the WildFly domain mode. > A new set of standalone examples > shows > how to use Camel in the context of JavaEE applications. > Ready available docker images are published as wildflyext/wildfly-camel > . > > For details, please have a look at the release notes > . > > cheers > ?thomas > > _______________________________________________ > 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/20141202/9782c4c7/attachment-0001.html From tdiesler at redhat.com Fri Dec 5 08:36:46 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Fri, 5 Dec 2014 14:36:46 +0100 Subject: [wildfly-dev] WildFly (domain) management in OpenShift V3 Message-ID: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> Folks, I?ve recently been looking at WildFly container deployments on OpenShift V3. The following setup is documented here The example architecture consists of a set of three high available (HA) servers running REST endpoints. For server replication and failover we use Kubernetes. Each server runs in a dedicated Pod that we access via Services. This approach comes with a number of benefits, which are sufficiently explained in various OpenShift , Kubernetes and Docker materials, but also with a number of challenges. Lets look at those in more detail ? In the example above Kubernetes replicates a number of standalone containers and isolates them in a Pod each with limited access from the outside world. * The management interfaces are not accessible * The management consoles are not visible With WildFly-Camel we have a Hawt.io console that allows us to manage Camel Routes configured or deployed to the WildFly runtime. The WildFly console manages aspects of the appserver. In a more general sense, I was wondering how the WildFly domain model maps to the Kubernetes runtime environment and how these server instances are managed and information about them relayed back to the sysadmin a) Should these individual wildfly instances somehow be connected to each other (i.e. notion of domain)? b) How would an HA singleton service work? c) What level of management should be exposed to the outside? d) Should it be possible to modify runtime behaviour of these servers (i.e. write access to config)? e) Should deployment be supported at all? f) How can a server be detected that has gone bad? g) Should logs be aggregated? h) Should there be a common management view (i.e. console) for these servers? i) etc ? Are these concerns already being addressed for WildFly? Is there perhaps even an already existing design that I could look at? Can such an effort be connected to the work that is going on in Fabric8? cheers ?thomas PS: it would be area that we @ wildfly-camel were interested to work on -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141205/42f4d229/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: example-rest-design.png Type: image/png Size: 20204 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141205/42f4d229/attachment-0001.png From brian.stansberry at redhat.com Fri Dec 5 14:00:02 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 05 Dec 2014 13:00:02 -0600 Subject: [wildfly-dev] WildFly (domain) management in OpenShift V3 In-Reply-To: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> Message-ID: <548200B2.30101@redhat.com> On 12/5/14, 7:36 AM, Thomas Diesler wrote: > Folks, > > I?ve recently been looking at WildFly container deployments on OpenShift > V3. The following setup is documented here > > > > The example architecture consists of a set of three high available > (HA) servers running REST endpoints. > For server replication and failover we use Kubernetes. Each server > runs in a dedicated Pod that we access via Services. > > This approach comes with a number of benefits, which are sufficiently > explained in various OpenShift > , > Kubernetes > and > Docker materials, but also with a number of > challenges. Lets look at those in more detail ? > > In the example above Kubernetes replicates a number of standalone > containers and isolates them in a Pod each with limited access from the > outside world. > > * The management interfaces are not accessible > * The management consoles are not visible > > With WildFly-Camel we have a Hawt.io > console > that allows us to manage Camel Routes configured or deployed to the > WildFly runtime. > The WildFly console manages aspects of the appserver. > > In a more general sense, I was wondering how the WildFly domain model > maps to the Kubernetes runtime environment and how these server > instances are managed and information about them relayed back to the > sysadmin > Your questions below mostly relate (correctly) to what *should* be done but I'll preface by discussing what *could* be done. Please forgive noob mistakes as I'm an admitted Kubernetes noob. AIUI a Kubernetes services exposes a single endpoint to outside callers, but the containers in the pods can open an arbitrary number of client connections to other services. This should work fine with WildFly domain management, as there can be a Service for the Domain Controller, which is the management interaction point for the sysadmin. And then the WildFly instance in the container for any other Service can connect and register with that Domain Controller service. The address/port those other containers use can be the same one that sysadmins use. > a) Should these individual wildfly instances somehow be connected to > each other (i.e. notion of domain)? Depends on the use case, but I expect certainly some users will centralized management, even if it's just for monitoring. > b) How would an HA singleton service work? WildFly *domain management* itself does not have an HA singleton notion, but i) Kubernetes replication controllers themselves provide a form of this, but I assume with a period of downtime while a new pod is spun up. ii) WildFly clustering has an HA singleton service concept that can be used. There are different mechanisms JGroups supports for group communication, but one involves each peer in the group connecting to a central coordination process. So presumably that coordination process could be deployed as a Kubernetes Service. > c) What level of management should be exposed to the outside? As much as possible this should be a user choice. Architecturally, I believe we can expose everything. I'm not real keen on trying to disable things in Kubernetes-specific ways. But I'm quite open to features to disable things that work in any deployment environment. > d) Should it be possible to modify runtime behaviour of these servers > (i.e. write access to config)? See c). We don't have a true read-only mode, athough I think it would be fairly straightforward to add such a thing if it were a requirement. > e) Should deployment be supported at all? See c). Making removing deployment capability configurable is also doable, although it's likely more work than a simple read-only mode. > f) How can a server be detected that has gone bad? I'll need to get a better understanding of Kubernetes to say anything useful about this. > g) Should logs be aggregated? This sounds like something that belongs at a higher layer, or as a general purpose WildFly feature unrelated to Kubernetes. > h) Should there be a common management view (i.e. console) for these > servers? I don't see why not. I think some users will want that, others won't, and others will want a console that spans things beyond WildFly servers. > i) etc ? > > Are these concerns already being addressed for WildFly? > Somewhat. As you can see from the above, a fair bit of stuff could just work. I know Heiko Braun has been thinking a bit about Kubernetes use cases too, or at least wanting to do so. ;) > Is there perhaps even an already existing design that I could look at? > Kubernetes specific stuff? No. > Can such an effort be connected to the work that is going on in Fabric8? > The primary Fabric8-related thing we (aka Alexey Loubyansky) are doing currently is working to support non-xml based persistence of our config files and a mechanism to support server detection of changes to the filesystem, triggering updates to the runtime. Goal being to integrate with the git-based mechanisms Fabric8 uses for configuration. https://developer.jboss.org/docs/DOC-52773 https://issues.jboss.org/browse/WFCORE-294 https://issues.jboss.org/browse/WFCORE-433 > cheers > ?thomas > > PS: it would be area that we @ wildfly-camel were interested to work on Great! :) -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From frank.langelage at osnanet.de Sat Dec 6 05:36:54 2014 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sat, 06 Dec 2014 11:36:54 +0100 Subject: [wildfly-dev] [INFO] WildFly: Infinispan Subsystem ...................... FAILURE [01:53 min] Message-ID: <5482DC46.6000303@osnanet.de> Running build with current master sources from github fails for me, if tests are enabled. Only smoke or more. See more detail below Anyone else seeing this problem? Running org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase Tests run: 18, Failures: 0, Errors: 2, Skipped: 16, Time elapsed: 17.593 sec <<< FAILURE! - in org.jboss.as.clustering.infinispan.subsystem.TransformersTestCasetestRejections720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase) Time elapsed: 9.824 sec <<< ERROR! java.lang.RuntimeException: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final from/to jboss-developer (http://repository.jboss.org/nexus/content/groups/developer/): Invalid Content-Range header for partial download: 580752-2662427/2662427 at org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496) at org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286) at org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235) at org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59) at org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447) at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350) at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581) at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294) at org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132) at org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197) at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800) at org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections(TransformersTestCase.java:356) at org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections720(TransformersTestCase.java:291) testTransformer720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase) Time elapsed: 7.617 sec <<< ERROR! java.lang.RuntimeException: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final from/to jboss-developer (http://repository.jboss.org/nexus/content/groups/developer/): Invalid Content-Range header for partial download: 580752-2662427/2662427 at org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496) at org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286) at org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235) at org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59) at org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447) at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350) at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581) at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294) at org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132) at org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197) at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800) at org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:183) at org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:177) at org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformation(TransformersTestCase.java:196) at org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformer720(TransformersTestCase.java:110) From eduardo.santanadasilva at gmail.com Sat Dec 6 06:51:49 2014 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Sat, 6 Dec 2014 09:51:49 -0200 Subject: [wildfly-dev] [INFO] WildFly: Infinispan Subsystem ...................... FAILURE [01:53 min] In-Reply-To: <5482DC46.6000303@osnanet.de> References: <5482DC46.6000303@osnanet.de> Message-ID: Hello, I've just had a successfully build using the latest commit (d9743c04277e115149d4c2bfb8dc54d9610e7928). Maybe you had some network issue regarding nexus repository at the time that you've tried to build the AS. Results : Tests run: 110, Failures: 0, Errors: 0, Skipped: 3 [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] WildFly: Parent Aggregator ......................... SUCCESS [ 6.615 s] [INFO] WildFly: Naming Subsystem .......................... SUCCESS [01:03 min] [INFO] WildFly: EE ........................................ SUCCESS [ 25.211 s] [INFO] WildFly: JacORB Subsystem .......................... SUCCESS [ 31.592 s] [INFO] WildFly: Transaction Subsystem ..................... SUCCESS [ 15.386 s] [INFO] WildFly: Clustering Subsystems ..................... SUCCESS [ 0.285 s] [INFO] WildFly: EE clustering ............................. SUCCESS [ 0.092 s] [INFO] WildFly: EE clustering SPI ......................... SUCCESS [ 0.746 s] [INFO] WildFly: EE clustering - Infinispan service provider SUCCESS [ 4.564 s] [INFO] WildFly: Common code for clustering subsystems ..... SUCCESS [ 6.793 s] [INFO] WildFly: Clustering SPI ............................ SUCCESS [ 1.357 s] [INFO] WildFly: JGroups Subsystem ......................... SUCCESS [ 23.739 s] [INFO] WildFly: Infinispan Subsystem ...................... SUCCESS [ 43.034 s] [INFO] WildFly: Security Subsystem parent ................. SUCCESS [ 0.158 s] [INFO] WildFly: Security Subsystem ........................ SUCCESS [ 17.346 s] [INFO] WildFly: Connector Subsystem ....................... SUCCESS [ 47.924 s] [INFO] WildFly: Clustering public API ..................... SUCCESS [ 1.203 s] [INFO] WildFly: SFSB clustering ........................... SUCCESS [ 0.178 s] [INFO] WildFly: SFSB clustering - SPI ..................... SUCCESS [ 1.304 s] [INFO] WildFly: EJB Subsystem ............................. SUCCESS [ 51.892 s] [INFO] WildFly: Web Common Classes ........................ SUCCESS [ 8.813 s] [INFO] WildFly: Web Subsystem ............................. SUCCESS [ 22.336 s] [INFO] WildFly: Undertow .................................. SUCCESS [ 30.091 s] [INFO] WildFly: Web Services Subsystem .................... SUCCESS [ 0.226 s] [INFO] WildFly: Web Services Server Integration Subsystem . SUCCESS [ 25.635 s] [INFO] WildFly: Application Client Bootstrap .............. SUCCESS [ 7.100 s] [INFO] WildFly: Batch Integration ......................... SUCCESS [ 0.421 s] [INFO] WildFly: JBeret Integration ........................ SUCCESS [ 2.134 s] [INFO] WildFly: Batch Integration Subsystem ............... SUCCESS [ 11.047 s] [INFO] WildFly: Bean Validation ........................... SUCCESS [ 9.722 s] [INFO] WildFly: Security Manager Subsystem ................ SUCCESS [ 8.612 s] [INFO] WildFly: Web Feature Pack .......................... SUCCESS [ 24.039 s] [INFO] WildFly: JPA Subsystem ............................. SUCCESS [ 15.117 s] [INFO] WildFly: Weld Integration .......................... SUCCESS [ 18.366 s] [INFO] WildFly: PicketLink Subsystem ...................... SUCCESS [ 34.422 s] [INFO] WildFly: Security Subsystem API .................... SUCCESS [ 1.413 s] [INFO] WildFly: JAX-RS Integration ........................ SUCCESS [ 14.239 s] [INFO] WildFly: RTS Subsystem ............................. SUCCESS [ 9.681 s] [INFO] WildFly: EJB Client BOM ............................ SUCCESS [ 0.297 s] [INFO] WildFly: JMS Client BOM ............................ SUCCESS [ 0.552 s] [INFO] WildFly: EJB and JMS client combined jar ........... SUCCESS [ 11.748 s] [INFO] WildFly: SFSB clustering - Infinispan integration .. SUCCESS [ 15.056 s] [INFO] WildFly: Singleton service API ..................... SUCCESS [ 3.628 s] [INFO] WildFly: Clustering API implementation ............. SUCCESS [ 4.875 s] [INFO] WildFly: Web session clustering .................... SUCCESS [ 0.282 s] [INFO] WildFly: Web session clustering API ................ SUCCESS [ 1.308 s] [INFO] WildFly: Web session clustering SPI ................ SUCCESS [ 1.236 s] [INFO] WildFly: Web session clustering - Infinispan service provider SUCCESS [ 10.960 s] [INFO] WildFly: Web session clustering - Undertow integration SUCCESS [ 10.379 s] [INFO] WildFly: EJB Container Managed Persistence Subsystem SUCCESS [ 10.034 s] [INFO] WildFly: Embedded .................................. SUCCESS [ 4.897 s] [INFO] WildFly: JAXR Client ............................... SUCCESS [ 10.292 s] [INFO] WildFly: JBoss Diagnostic Reporter ................. SUCCESS [ 0.148 s] [INFO] WildFly: JDR ....................................... SUCCESS [ 15.688 s] [INFO] WildFly: JSF ....................................... SUCCESS [ 0.409 s] [INFO] WildFly: JSF Subsystem ............................. SUCCESS [ 12.490 s] [INFO] WildFly: JSF Injection Handlers .................... SUCCESS [ 3.388 s] [INFO] WildFly: JSR-77 Subsystem .......................... SUCCESS [ 19.523 s] [INFO] WildFly: Mail subsystem ............................ SUCCESS [ 16.446 s] [INFO] WildFly: Messaging Subsystem ....................... SUCCESS [01:06 min] [INFO] WildFly: mod_cluster Subsystem ..................... SUCCESS [ 0.213 s] [INFO] WildFly: mod_cluster Extension ..................... SUCCESS [ 21.079 s] [INFO] WildFly: mod_cluster Undertow Integration .......... SUCCESS [ 6.887 s] [INFO] WildFly: POJO Subsystem ............................ SUCCESS [ 12.144 s] [INFO] WildFly: Service Archive Subsystem ................. SUCCESS [ 8.272 s] [INFO] WildFly: XTS Subsystem ............................. SUCCESS [ 10.071 s] [INFO] WildFly: Full Feature Pack ......................... SUCCESS [01:00 min] [INFO] WildFly: Build ..................................... SUCCESS [ 57.762 s] [INFO] WildFly: Distribution .............................. SUCCESS [ 59.827 s] [INFO] WildFly: JSF Multi-JSF installer ................... SUCCESS [ 10.179 s] [INFO] WildFly: Exported Java EE Specification APIs ....... SUCCESS [ 0.206 s] [INFO] WildFly: Validation Tests for Exported Java EE Specification APIs SUCCESS [ 0.398 s] [INFO] WildFly: Build Web ................................. SUCCESS [ 2.453 s] [INFO] WildFly: Web Distribution .......................... SUCCESS [ 6.460 s] [INFO] WildFly: Web Services Tests Integration Subsystem .. SUCCESS [ 7.065 s] [INFO] WildFly Test Suite: Shared ......................... SUCCESS [ 17.882 s] [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS [ 58.195 s] [INFO] WildFly Test Suite: Integration .................... SUCCESS [ 9.865 s] [INFO] WildFly Test Suite: Integration - Web .............. SUCCESS [01:42 min] [INFO] WildFly Test Suite: Integration - Smoke ............ SUCCESS [03:41 min] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 24:55 min [INFO] Finished at: 2014-12-06T09:33:11-02:00 [INFO] Final Memory: 281M/705M [INFO] ------------------------------------------------------------------------ On Dec 6, 2014, at 8:36 AM, Frank Langelage wrote: > Running build with current master sources from github fails for me, if > tests are enabled. Only smoke or more. > See more detail below > > Anyone else seeing this problem? > > > Running org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase > Tests run: 18, Failures: 0, Errors: 2, Skipped: 16, Time elapsed: 17.593 > sec <<< FAILURE! - in > org.jboss.as.clustering.infinispan.subsystem.TransformersTestCasetestRejections720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase) > Time elapsed: 9.824 sec <<< ERROR! > java.lang.RuntimeException: > org.eclipse.aether.resolution.ArtifactResolutionException: Could not > transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final from/to > jboss-developer > (http://repository.jboss.org/nexus/content/groups/developer/): Invalid > Content-Range header for partial download: 580752-2662427/2662427 > at > org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496) > at > org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286) > at > org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235) > at > org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350) > at > org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294) > at > org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132) > at > org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197) > at > org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800) > at > org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections(TransformersTestCase.java:356) > at > org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections720(TransformersTestCase.java:291) > > testTransformer720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase) > Time elapsed: 7.617 sec <<< ERROR! > java.lang.RuntimeException: > org.eclipse.aether.resolution.ArtifactResolutionException: Could not > transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final from/to > jboss-developer > (http://repository.jboss.org/nexus/content/groups/developer/): Invalid > Content-Range header for partial download: 580752-2662427/2662427 > at > org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496) > at > org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286) > at > org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235) > at > org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350) > at > org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581) > at > org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294) > at > org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132) > at > org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197) > at > org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800) > at > org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:183) > at > org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:177) > at > org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformation(TransformersTestCase.java:196) > at > org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformer720(TransformersTestCase.java:110) > > > _______________________________________________ > 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/20141206/aa8b578a/attachment-0001.html From frank.langelage at osnanet.de Sat Dec 6 17:28:53 2014 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sat, 06 Dec 2014 23:28:53 +0100 Subject: [wildfly-dev] [INFO] WildFly: Infinispan Subsystem ...................... FAILURE [01:53 min] In-Reply-To: References: <5482DC46.6000303@osnanet.de> Message-ID: <54838325.5070707@osnanet.de> No, it's reproducible for some days now. Downloads of new versions / updated components like wildfly core and JGroups today happen without any problems. On 06.12.14 12:51, Eduardo Sant'Ana da Silva wrote: > Hello, > > I've just had a successfully build using the latest commit > (d9743c04277e115149d4c2bfb8dc54d9610e7928). > Maybe you had some network issue regarding nexus repository at the > time that you've tried to build the AS. > > > Results : > > Tests run: 110, Failures: 0, Errors: 0, Skipped: 3 > > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] WildFly: Parent Aggregator ......................... SUCCESS [ > 6.615 s] > [INFO] WildFly: Naming Subsystem .......................... SUCCESS > [01:03 min] > [INFO] WildFly: EE ........................................ SUCCESS [ > 25.211 s] > [INFO] WildFly: JacORB Subsystem .......................... SUCCESS [ > 31.592 s] > [INFO] WildFly: Transaction Subsystem ..................... SUCCESS [ > 15.386 s] > [INFO] WildFly: Clustering Subsystems ..................... SUCCESS [ > 0.285 s] > [INFO] WildFly: EE clustering ............................. SUCCESS [ > 0.092 s] > [INFO] WildFly: EE clustering SPI ......................... SUCCESS [ > 0.746 s] > [INFO] WildFly: EE clustering - Infinispan service provider SUCCESS [ > 4.564 s] > [INFO] WildFly: Common code for clustering subsystems ..... SUCCESS [ > 6.793 s] > [INFO] WildFly: Clustering SPI ............................ SUCCESS [ > 1.357 s] > [INFO] WildFly: JGroups Subsystem ......................... SUCCESS [ > 23.739 s] > [INFO] WildFly: Infinispan Subsystem ...................... SUCCESS [ > 43.034 s] > [INFO] WildFly: Security Subsystem parent ................. SUCCESS [ > 0.158 s] > [INFO] WildFly: Security Subsystem ........................ SUCCESS [ > 17.346 s] > [INFO] WildFly: Connector Subsystem ....................... SUCCESS [ > 47.924 s] > [INFO] WildFly: Clustering public API ..................... SUCCESS [ > 1.203 s] > [INFO] WildFly: SFSB clustering ........................... SUCCESS [ > 0.178 s] > [INFO] WildFly: SFSB clustering - SPI ..................... SUCCESS [ > 1.304 s] > [INFO] WildFly: EJB Subsystem ............................. SUCCESS [ > 51.892 s] > [INFO] WildFly: Web Common Classes ........................ SUCCESS [ > 8.813 s] > [INFO] WildFly: Web Subsystem ............................. SUCCESS [ > 22.336 s] > [INFO] WildFly: Undertow .................................. SUCCESS [ > 30.091 s] > [INFO] WildFly: Web Services Subsystem .................... SUCCESS [ > 0.226 s] > [INFO] WildFly: Web Services Server Integration Subsystem . SUCCESS [ > 25.635 s] > [INFO] WildFly: Application Client Bootstrap .............. SUCCESS [ > 7.100 s] > [INFO] WildFly: Batch Integration ......................... SUCCESS [ > 0.421 s] > [INFO] WildFly: JBeret Integration ........................ SUCCESS [ > 2.134 s] > [INFO] WildFly: Batch Integration Subsystem ............... SUCCESS [ > 11.047 s] > [INFO] WildFly: Bean Validation ........................... SUCCESS [ > 9.722 s] > [INFO] WildFly: Security Manager Subsystem ................ SUCCESS [ > 8.612 s] > [INFO] WildFly: Web Feature Pack .......................... SUCCESS [ > 24.039 s] > [INFO] WildFly: JPA Subsystem ............................. SUCCESS [ > 15.117 s] > [INFO] WildFly: Weld Integration .......................... SUCCESS [ > 18.366 s] > [INFO] WildFly: PicketLink Subsystem ...................... SUCCESS [ > 34.422 s] > [INFO] WildFly: Security Subsystem API .................... SUCCESS [ > 1.413 s] > [INFO] WildFly: JAX-RS Integration ........................ SUCCESS [ > 14.239 s] > [INFO] WildFly: RTS Subsystem ............................. SUCCESS [ > 9.681 s] > [INFO] WildFly: EJB Client BOM ............................ SUCCESS [ > 0.297 s] > [INFO] WildFly: JMS Client BOM ............................ SUCCESS [ > 0.552 s] > [INFO] WildFly: EJB and JMS client combined jar ........... SUCCESS [ > 11.748 s] > [INFO] WildFly: SFSB clustering - Infinispan integration .. SUCCESS [ > 15.056 s] > [INFO] WildFly: Singleton service API ..................... SUCCESS [ > 3.628 s] > [INFO] WildFly: Clustering API implementation ............. SUCCESS [ > 4.875 s] > [INFO] WildFly: Web session clustering .................... SUCCESS [ > 0.282 s] > [INFO] WildFly: Web session clustering API ................ SUCCESS [ > 1.308 s] > [INFO] WildFly: Web session clustering SPI ................ SUCCESS [ > 1.236 s] > [INFO] WildFly: Web session clustering - Infinispan service provider > SUCCESS [ 10.960 s] > [INFO] WildFly: Web session clustering - Undertow integration SUCCESS > [ 10.379 s] > [INFO] WildFly: EJB Container Managed Persistence Subsystem SUCCESS [ > 10.034 s] > [INFO] WildFly: Embedded .................................. SUCCESS [ > 4.897 s] > [INFO] WildFly: JAXR Client ............................... SUCCESS [ > 10.292 s] > [INFO] WildFly: JBoss Diagnostic Reporter ................. SUCCESS [ > 0.148 s] > [INFO] WildFly: JDR ....................................... SUCCESS [ > 15.688 s] > [INFO] WildFly: JSF ....................................... SUCCESS [ > 0.409 s] > [INFO] WildFly: JSF Subsystem ............................. SUCCESS [ > 12.490 s] > [INFO] WildFly: JSF Injection Handlers .................... SUCCESS [ > 3.388 s] > [INFO] WildFly: JSR-77 Subsystem .......................... SUCCESS [ > 19.523 s] > [INFO] WildFly: Mail subsystem ............................ SUCCESS [ > 16.446 s] > [INFO] WildFly: Messaging Subsystem ....................... SUCCESS > [01:06 min] > [INFO] WildFly: mod_cluster Subsystem ..................... SUCCESS [ > 0.213 s] > [INFO] WildFly: mod_cluster Extension ..................... SUCCESS [ > 21.079 s] > [INFO] WildFly: mod_cluster Undertow Integration .......... SUCCESS [ > 6.887 s] > [INFO] WildFly: POJO Subsystem ............................ SUCCESS [ > 12.144 s] > [INFO] WildFly: Service Archive Subsystem ................. SUCCESS [ > 8.272 s] > [INFO] WildFly: XTS Subsystem ............................. SUCCESS [ > 10.071 s] > [INFO] WildFly: Full Feature Pack ......................... SUCCESS > [01:00 min] > [INFO] WildFly: Build ..................................... SUCCESS [ > 57.762 s] > [INFO] WildFly: Distribution .............................. SUCCESS [ > 59.827 s] > [INFO] WildFly: JSF Multi-JSF installer ................... SUCCESS [ > 10.179 s] > [INFO] WildFly: Exported Java EE Specification APIs ....... SUCCESS [ > 0.206 s] > [INFO] WildFly: Validation Tests for Exported Java EE Specification > APIs SUCCESS [ 0.398 s] > [INFO] WildFly: Build Web ................................. SUCCESS [ > 2.453 s] > [INFO] WildFly: Web Distribution .......................... SUCCESS [ > 6.460 s] > [INFO] WildFly: Web Services Tests Integration Subsystem .. SUCCESS [ > 7.065 s] > [INFO] WildFly Test Suite: Shared ......................... SUCCESS [ > 17.882 s] > [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS [ > 58.195 s] > [INFO] WildFly Test Suite: Integration .................... SUCCESS [ > 9.865 s] > [INFO] WildFly Test Suite: Integration - Web .............. SUCCESS > [01:42 min] > [INFO] WildFly Test Suite: Integration - Smoke ............ SUCCESS > [03:41 min] > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 24:55 min > [INFO] Finished at: 2014-12-06T09:33:11-02:00 > [INFO] Final Memory: 281M/705M > [INFO] > ------------------------------------------------------------------------ > > On Dec 6, 2014, at 8:36 AM, Frank Langelage > > wrote: > >> Running build with current master sources from github fails for me, if >> tests are enabled. Only smoke or more. >> See more detail below >> >> Anyone else seeing this problem? >> >> >> Running org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase >> Tests run: 18, Failures: 0, Errors: 2, Skipped: 16, Time elapsed: 17.593 >> sec <<< FAILURE! - in >> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCasetestRejections720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase) >> >> Time elapsed: 9.824 sec <<< ERROR! >> java.lang.RuntimeException: >> org.eclipse.aether.resolution.ArtifactResolutionException: Could not >> transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final from/to >> jboss-developer >> (http://repository.jboss.org/nexus/content/groups/developer/): Invalid >> Content-Range header for partial download: 580752-2662427/2662427 >> at >> org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496) >> at >> org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286) >> at >> org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235) >> at >> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59) >> at >> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447) >> at >> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350) >> at >> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) >> at >> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581) >> at >> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249) >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520) >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246) >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223) >> at >> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294) >> at >> org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132) >> at >> org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197) >> at >> org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800) >> at >> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections(TransformersTestCase.java:356) >> at >> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections720(TransformersTestCase.java:291) >> >> testTransformer720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase) >> >> Time elapsed: 7.617 sec <<< ERROR! >> java.lang.RuntimeException: >> org.eclipse.aether.resolution.ArtifactResolutionException: Could not >> transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final from/to >> jboss-developer >> (http://repository.jboss.org/nexus/content/groups/developer/): Invalid >> Content-Range header for partial download: 580752-2662427/2662427 >> at >> org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496) >> at >> org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286) >> at >> org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235) >> at >> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59) >> at >> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447) >> at >> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350) >> at >> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) >> at >> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581) >> at >> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249) >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520) >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246) >> at >> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223) >> at >> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294) >> at >> org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132) >> at >> org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197) >> at >> org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800) >> at >> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:183) >> at >> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:177) >> at >> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformation(TransformersTestCase.java:196) >> at >> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformer720(TransformersTestCase.java:110) >> >> >> _______________________________________________ >> 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/20141206/2654fbef/attachment-0001.html From arun.gupta at gmail.com Sat Dec 6 19:12:23 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Sat, 6 Dec 2014 16:12:23 -0800 Subject: [wildfly-dev] WildFly memory consumption Message-ID: WildFly consuming 66.8% of 1GB VM. https://twitter.com/htmfilho/status/541359752069267456 I don't see that behavior on my machine and following up on the thread. Any clues on what might be different in the setup by the user ? Arun -- http://blog.arungupta.me http://twitter.com/arungupta From stuart.w.douglas at gmail.com Sat Dec 6 19:13:44 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Sun, 07 Dec 2014 11:13:44 +1100 Subject: [wildfly-dev] WildFly memory consumption In-Reply-To: References: Message-ID: <54839BB8.9030104@gmail.com> My money would be on something in the users app. Stuart Arun Gupta wrote: > WildFly consuming 66.8% of 1GB VM. > > https://twitter.com/htmfilho/status/541359752069267456 > > I don't see that behavior on my machine and following up on the > thread. Any clues on what might be different in the setup by the user > ? > > Arun > From frank.langelage at osnanet.de Sun Dec 7 17:59:38 2014 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sun, 07 Dec 2014 23:59:38 +0100 Subject: [wildfly-dev] [INFO] WildFly: Infinispan Subsystem ...................... FAILURE [01:53 min] In-Reply-To: <54838325.5070707@osnanet.de> References: <5482DC46.6000303@osnanet.de> <54838325.5070707@osnanet.de> Message-ID: <5484DBDA.8020509@osnanet.de> I removed the complete folder $HOME/.m2/repository and did a new build. Now everything is working again. On 06.12.14 23:28, Frank Langelage wrote: > No, it's reproducible for some days now. > Downloads of new versions / updated components like wildfly core and > JGroups today happen without any problems. > > > On 06.12.14 12:51, Eduardo Sant'Ana da Silva wrote: >> Hello, >> >> I've just had a successfully build using the latest commit >> (d9743c04277e115149d4c2bfb8dc54d9610e7928). >> Maybe you had some network issue regarding nexus repository at the >> time that you've tried to build the AS. >> >> >> Results : >> >> Tests run: 110, Failures: 0, Errors: 0, Skipped: 3 >> >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Reactor Summary: >> [INFO] >> [INFO] WildFly: Parent Aggregator ......................... SUCCESS >> [ 6.615 s] >> [INFO] WildFly: Naming Subsystem .......................... SUCCESS >> [01:03 min] >> [INFO] WildFly: EE ........................................ SUCCESS [ >> 25.211 s] >> [INFO] WildFly: JacORB Subsystem .......................... SUCCESS [ >> 31.592 s] >> [INFO] WildFly: Transaction Subsystem ..................... SUCCESS [ >> 15.386 s] >> [INFO] WildFly: Clustering Subsystems ..................... SUCCESS >> [ 0.285 s] >> [INFO] WildFly: EE clustering ............................. SUCCESS >> [ 0.092 s] >> [INFO] WildFly: EE clustering SPI ......................... SUCCESS >> [ 0.746 s] >> [INFO] WildFly: EE clustering - Infinispan service provider SUCCESS >> [ 4.564 s] >> [INFO] WildFly: Common code for clustering subsystems ..... SUCCESS >> [ 6.793 s] >> [INFO] WildFly: Clustering SPI ............................ SUCCESS >> [ 1.357 s] >> [INFO] WildFly: JGroups Subsystem ......................... SUCCESS [ >> 23.739 s] >> [INFO] WildFly: Infinispan Subsystem ...................... SUCCESS [ >> 43.034 s] >> [INFO] WildFly: Security Subsystem parent ................. SUCCESS >> [ 0.158 s] >> [INFO] WildFly: Security Subsystem ........................ SUCCESS [ >> 17.346 s] >> [INFO] WildFly: Connector Subsystem ....................... SUCCESS [ >> 47.924 s] >> [INFO] WildFly: Clustering public API ..................... SUCCESS >> [ 1.203 s] >> [INFO] WildFly: SFSB clustering ........................... SUCCESS >> [ 0.178 s] >> [INFO] WildFly: SFSB clustering - SPI ..................... SUCCESS >> [ 1.304 s] >> [INFO] WildFly: EJB Subsystem ............................. SUCCESS [ >> 51.892 s] >> [INFO] WildFly: Web Common Classes ........................ SUCCESS >> [ 8.813 s] >> [INFO] WildFly: Web Subsystem ............................. SUCCESS [ >> 22.336 s] >> [INFO] WildFly: Undertow .................................. SUCCESS [ >> 30.091 s] >> [INFO] WildFly: Web Services Subsystem .................... SUCCESS >> [ 0.226 s] >> [INFO] WildFly: Web Services Server Integration Subsystem . SUCCESS [ >> 25.635 s] >> [INFO] WildFly: Application Client Bootstrap .............. SUCCESS >> [ 7.100 s] >> [INFO] WildFly: Batch Integration ......................... SUCCESS >> [ 0.421 s] >> [INFO] WildFly: JBeret Integration ........................ SUCCESS >> [ 2.134 s] >> [INFO] WildFly: Batch Integration Subsystem ............... SUCCESS [ >> 11.047 s] >> [INFO] WildFly: Bean Validation ........................... SUCCESS >> [ 9.722 s] >> [INFO] WildFly: Security Manager Subsystem ................ SUCCESS >> [ 8.612 s] >> [INFO] WildFly: Web Feature Pack .......................... SUCCESS [ >> 24.039 s] >> [INFO] WildFly: JPA Subsystem ............................. SUCCESS [ >> 15.117 s] >> [INFO] WildFly: Weld Integration .......................... SUCCESS [ >> 18.366 s] >> [INFO] WildFly: PicketLink Subsystem ...................... SUCCESS [ >> 34.422 s] >> [INFO] WildFly: Security Subsystem API .................... SUCCESS >> [ 1.413 s] >> [INFO] WildFly: JAX-RS Integration ........................ SUCCESS [ >> 14.239 s] >> [INFO] WildFly: RTS Subsystem ............................. SUCCESS >> [ 9.681 s] >> [INFO] WildFly: EJB Client BOM ............................ SUCCESS >> [ 0.297 s] >> [INFO] WildFly: JMS Client BOM ............................ SUCCESS >> [ 0.552 s] >> [INFO] WildFly: EJB and JMS client combined jar ........... SUCCESS [ >> 11.748 s] >> [INFO] WildFly: SFSB clustering - Infinispan integration .. SUCCESS [ >> 15.056 s] >> [INFO] WildFly: Singleton service API ..................... SUCCESS >> [ 3.628 s] >> [INFO] WildFly: Clustering API implementation ............. SUCCESS >> [ 4.875 s] >> [INFO] WildFly: Web session clustering .................... SUCCESS >> [ 0.282 s] >> [INFO] WildFly: Web session clustering API ................ SUCCESS >> [ 1.308 s] >> [INFO] WildFly: Web session clustering SPI ................ SUCCESS >> [ 1.236 s] >> [INFO] WildFly: Web session clustering - Infinispan service provider >> SUCCESS [ 10.960 s] >> [INFO] WildFly: Web session clustering - Undertow integration SUCCESS >> [ 10.379 s] >> [INFO] WildFly: EJB Container Managed Persistence Subsystem SUCCESS [ >> 10.034 s] >> [INFO] WildFly: Embedded .................................. SUCCESS >> [ 4.897 s] >> [INFO] WildFly: JAXR Client ............................... SUCCESS [ >> 10.292 s] >> [INFO] WildFly: JBoss Diagnostic Reporter ................. SUCCESS >> [ 0.148 s] >> [INFO] WildFly: JDR ....................................... SUCCESS [ >> 15.688 s] >> [INFO] WildFly: JSF ....................................... SUCCESS >> [ 0.409 s] >> [INFO] WildFly: JSF Subsystem ............................. SUCCESS [ >> 12.490 s] >> [INFO] WildFly: JSF Injection Handlers .................... SUCCESS >> [ 3.388 s] >> [INFO] WildFly: JSR-77 Subsystem .......................... SUCCESS [ >> 19.523 s] >> [INFO] WildFly: Mail subsystem ............................ SUCCESS [ >> 16.446 s] >> [INFO] WildFly: Messaging Subsystem ....................... SUCCESS >> [01:06 min] >> [INFO] WildFly: mod_cluster Subsystem ..................... SUCCESS >> [ 0.213 s] >> [INFO] WildFly: mod_cluster Extension ..................... SUCCESS [ >> 21.079 s] >> [INFO] WildFly: mod_cluster Undertow Integration .......... SUCCESS >> [ 6.887 s] >> [INFO] WildFly: POJO Subsystem ............................ SUCCESS [ >> 12.144 s] >> [INFO] WildFly: Service Archive Subsystem ................. SUCCESS >> [ 8.272 s] >> [INFO] WildFly: XTS Subsystem ............................. SUCCESS [ >> 10.071 s] >> [INFO] WildFly: Full Feature Pack ......................... SUCCESS >> [01:00 min] >> [INFO] WildFly: Build ..................................... SUCCESS [ >> 57.762 s] >> [INFO] WildFly: Distribution .............................. SUCCESS [ >> 59.827 s] >> [INFO] WildFly: JSF Multi-JSF installer ................... SUCCESS [ >> 10.179 s] >> [INFO] WildFly: Exported Java EE Specification APIs ....... SUCCESS >> [ 0.206 s] >> [INFO] WildFly: Validation Tests for Exported Java EE Specification >> APIs SUCCESS [ 0.398 s] >> [INFO] WildFly: Build Web ................................. SUCCESS >> [ 2.453 s] >> [INFO] WildFly: Web Distribution .......................... SUCCESS >> [ 6.460 s] >> [INFO] WildFly: Web Services Tests Integration Subsystem .. SUCCESS >> [ 7.065 s] >> [INFO] WildFly Test Suite: Shared ......................... SUCCESS [ >> 17.882 s] >> [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS [ >> 58.195 s] >> [INFO] WildFly Test Suite: Integration .................... SUCCESS >> [ 9.865 s] >> [INFO] WildFly Test Suite: Integration - Web .............. SUCCESS >> [01:42 min] >> [INFO] WildFly Test Suite: Integration - Smoke ............ SUCCESS >> [03:41 min] >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] BUILD SUCCESS >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Total time: 24:55 min >> [INFO] Finished at: 2014-12-06T09:33:11-02:00 >> [INFO] Final Memory: 281M/705M >> [INFO] >> ------------------------------------------------------------------------ >> >> On Dec 6, 2014, at 8:36 AM, Frank Langelage >> > wrote: >> >>> Running build with current master sources from github fails for me, if >>> tests are enabled. Only smoke or more. >>> See more detail below >>> >>> Anyone else seeing this problem? >>> >>> >>> Running >>> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase >>> Tests run: 18, Failures: 0, Errors: 2, Skipped: 16, Time elapsed: >>> 17.593 >>> sec <<< FAILURE! - in >>> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCasetestRejections720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase) >>> >>> Time elapsed: 9.824 sec <<< ERROR! >>> java.lang.RuntimeException: >>> org.eclipse.aether.resolution.ArtifactResolutionException: Could not >>> transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final >>> from/to >>> jboss-developer >>> (http://repository.jboss.org/nexus/content/groups/developer/): Invalid >>> Content-Range header for partial download: 580752-2662427/2662427 >>> at >>> org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496) >>> at >>> org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286) >>> at >>> org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235) >>> at >>> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59) >>> at >>> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447) >>> at >>> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350) >>> at >>> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) >>> at >>> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581) >>> at >>> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249) >>> at >>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520) >>> at >>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) >>> at >>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246) >>> at >>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223) >>> at >>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294) >>> at >>> org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132) >>> at >>> org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197) >>> at >>> org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800) >>> at >>> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections(TransformersTestCase.java:356) >>> at >>> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testRejections720(TransformersTestCase.java:291) >>> >>> testTransformer720(org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase) >>> >>> Time elapsed: 7.617 sec <<< ERROR! >>> java.lang.RuntimeException: >>> org.eclipse.aether.resolution.ArtifactResolutionException: Could not >>> transfer artifact org.infinispan:infinispan-core:jar:5.3.0.Final >>> from/to >>> jboss-developer >>> (http://repository.jboss.org/nexus/content/groups/developer/): Invalid >>> Content-Range header for partial download: 580752-2662427/2662427 >>> at >>> org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle(HttpTransporter.java:496) >>> at >>> org.eclipse.aether.transport.http.HttpTransporter.execute(HttpTransporter.java:286) >>> at >>> org.eclipse.aether.transport.http.HttpTransporter.implGet(HttpTransporter.java:235) >>> at >>> org.eclipse.aether.spi.connector.transport.AbstractTransporter.get(AbstractTransporter.java:59) >>> at >>> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:447) >>> at >>> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:350) >>> at >>> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) >>> at >>> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581) >>> at >>> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249) >>> at >>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520) >>> at >>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421) >>> at >>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246) >>> at >>> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223) >>> at >>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294) >>> at >>> org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:132) >>> at >>> org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197) >>> at >>> org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.addMavenResourceURL(SubsystemTestDelegate.java:800) >>> at >>> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:183) >>> at >>> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.buildKernelServices(TransformersTestCase.java:177) >>> at >>> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformation(TransformersTestCase.java:196) >>> at >>> org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase.testTransformer720(TransformersTestCase.java:110) >>> >>> >>> _______________________________________________ >>> 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/20141207/9fa68720/attachment-0001.html From tdiesler at redhat.com Mon Dec 8 04:08:33 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Mon, 8 Dec 2014 10:08:33 +0100 Subject: [wildfly-dev] WildFly (domain) management in OpenShift V3 In-Reply-To: <548200B2.30101@redhat.com> References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> <548200B2.30101@redhat.com> Message-ID: <211F5A56-7253-4547-A9DC-4AD0010E8A4C@redhat.com> Thank Brian, I?d like to do a little more research with wildfly domain mode in openshift before responding. Won?t be long ... > On 5 Dec 2014, at 20:00, Brian Stansberry wrote: > > On 12/5/14, 7:36 AM, Thomas Diesler wrote: >> Folks, >> >> I?ve recently been looking at WildFly container deployments on OpenShift >> V3. The following setup is documented here >> >> >> >> The example architecture consists of a set of three high available >> (HA) servers running REST endpoints. >> For server replication and failover we use Kubernetes. Each server >> runs in a dedicated Pod that we access via Services. >> >> This approach comes with a number of benefits, which are sufficiently >> explained in various OpenShift >> , >> Kubernetes >> and >> Docker materials, but also with a number of >> challenges. Lets look at those in more detail ? >> >> In the example above Kubernetes replicates a number of standalone >> containers and isolates them in a Pod each with limited access from the >> outside world. >> >> * The management interfaces are not accessible >> * The management consoles are not visible >> >> With WildFly-Camel we have a Hawt.io >> console >> that allows us to manage Camel Routes configured or deployed to the >> WildFly runtime. >> The WildFly console manages aspects of the appserver. >> >> In a more general sense, I was wondering how the WildFly domain model >> maps to the Kubernetes runtime environment and how these server >> instances are managed and information about them relayed back to the >> sysadmin >> > > Your questions below mostly relate (correctly) to what *should* be done > but I'll preface by discussing what *could* be done. Please forgive noob > mistakes as I'm an admitted Kubernetes noob. > > AIUI a Kubernetes services exposes a single endpoint to outside callers, > but the containers in the pods can open an arbitrary number of client > connections to other services. > > This should work fine with WildFly domain management, as there can be a > Service for the Domain Controller, which is the management interaction > point for the sysadmin. And then the WildFly instance in the container > for any other Service can connect and register with that Domain > Controller service. The address/port those other containers use can be > the same one that sysadmins use. > >> a) Should these individual wildfly instances somehow be connected to >> each other (i.e. notion of domain)? > > Depends on the use case, but I expect certainly some users will > centralized management, even if it's just for monitoring. > >> b) How would an HA singleton service work? > > WildFly *domain management* itself does not have an HA singleton notion, but > > i) Kubernetes replication controllers themselves provide a form of this, > but I assume with a period of downtime while a new pod is spun up. > > ii) WildFly clustering has an HA singleton service concept that can be > used. There are different mechanisms JGroups supports for group > communication, but one involves each peer in the group connecting to a > central coordination process. So presumably that coordination process > could be deployed as a Kubernetes Service. > >> c) What level of management should be exposed to the outside? > > As much as possible this should be a user choice. Architecturally, I > believe we can expose everything. I'm not real keen on trying to disable > things in Kubernetes-specific ways. But I'm quite open to features to > disable things that work in any deployment environment. > >> d) Should it be possible to modify runtime behaviour of these servers >> (i.e. write access to config)? > > See c). We don't have a true read-only mode, athough I think it would be > fairly straightforward to add such a thing if it were a requirement. > >> e) Should deployment be supported at all? > > See c). Making removing deployment capability configurable is also > doable, although it's likely more work than a simple read-only mode. > >> f) How can a server be detected that has gone bad? > > I'll need to get a better understanding of Kubernetes to say anything > useful about this. > >> g) Should logs be aggregated? > > This sounds like something that belongs at a higher layer, or as a > general purpose WildFly feature unrelated to Kubernetes. > >> h) Should there be a common management view (i.e. console) for these >> servers? > > I don't see why not. I think some users will want that, others won't, > and others will want a console that spans things beyond WildFly servers. > >> i) etc ? >> >> Are these concerns already being addressed for WildFly? >> > > Somewhat. As you can see from the above, a fair bit of stuff could just > work. I know Heiko Braun has been thinking a bit about Kubernetes use > cases too, or at least wanting to do so. ;) > >> Is there perhaps even an already existing design that I could look at? >> > > Kubernetes specific stuff? No. > >> Can such an effort be connected to the work that is going on in Fabric8? >> > > The primary Fabric8-related thing we (aka Alexey Loubyansky) are doing > currently is working to support non-xml based persistence of our config > files and a mechanism to support server detection of changes to the > filesystem, triggering updates to the runtime. Goal being to integrate > with the git-based mechanisms Fabric8 uses for configuration. > > https://developer.jboss.org/docs/DOC-52773 > https://issues.jboss.org/browse/WFCORE-294 > https://issues.jboss.org/browse/WFCORE-433 > >> cheers >> ?thomas >> >> PS: it would be area that we @ wildfly-camel were interested to work on > > Great! :) > > -- > Brian Stansberry > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141208/71822768/attachment.html From claudio at claudius.com.br Mon Dec 8 09:09:40 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Mon, 8 Dec 2014 12:09:40 -0200 Subject: [wildfly-dev] Change WebServices subsystem to use PersistentResourceXMLDescription Message-ID: Hi, to better understand subsystem api, I am changing the WS subsystem to use the PersistentResourceXMLDescription, more in line with the other subsystem api. There are some wsdl settings, they are xml elements. ${ws.modify-wsdl-address:true} ${jboss.bind.address:localhost} ${ws.wsdl-port:9090} ${ws.wsdl-secure-port:9443} https s/jaxws-jbws2150-codefirst/xx\/jaxws-jbws2150-codefirst/g What do you think of those settings as attributes ? Later I can submit it for review if is of interest. Kind regards -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From tomaz.cerar at gmail.com Mon Dec 8 09:17:49 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 8 Dec 2014 15:17:49 +0100 Subject: [wildfly-dev] Change WebServices subsystem to use PersistentResourceXMLDescription In-Reply-To: References: Message-ID: IMO it makes perfect sense as all that attributes are all on on resource. On Mon, Dec 8, 2014 at 3:09 PM, Claudio Miranda wrote: > Hi, to better understand subsystem api, I am changing the WS subsystem > to use the PersistentResourceXMLDescription, more in line with the > other subsystem api. > > There are some wsdl settings, they are xml elements. > > > > ${ws.modify-wsdl-address:true} > ${jboss.bind.address:localhost} > ${ws.wsdl-port:9090} > ${ws.wsdl-secure-port:9443} > https > > s/jaxws-jbws2150-codefirst/xx\/jaxws-jbws2150-codefirst/g > > > What do you think of those settings as attributes ? > > > wsdl-host="${jboss.bind.address:localhost}" > wsdl-port="${ws.wsdl-port:9090}" > wsdl-secure-port="${ws.wsdl-secure-port:9443}" > wsdl-uri-scheme="https" > > wsdl-path-rewrite-rule="s/jaxws-jbws2150-codefirst/xx\/jaxws-jbws2150-codefirst/g"/> > > > Later I can submit it for review if is of interest. > > Kind regards > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > 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/20141208/f310f295/attachment.html From brian.stansberry at redhat.com Mon Dec 8 10:00:50 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 08 Dec 2014 09:00:50 -0600 Subject: [wildfly-dev] Change WebServices subsystem to use PersistentResourceXMLDescription In-Reply-To: References: Message-ID: <5485BD22.1040406@redhat.com> On 12/8/14, 8:09 AM, Claudio Miranda wrote: > > > Later I can submit it for review if is of interest. Look for a response from Alessio Soldano as I'd ask him to approve the PR anyway. I definitely prefer attributes to text elements. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From rory.odonnell at oracle.com Tue Dec 9 03:41:38 2014 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 09 Dec 2014 08:41:38 +0000 Subject: [wildfly-dev] JDK 9 images are now modular with JDK 9 Early Access build 41 Message-ID: <5486B5C2.9080900@oracle.com> Hi Jason/Tomaz, The initial changesets for JEP 220: Modular Run-Time Images [1] are available with JDK 9 early-access build 41 [2]. To summarize (please see the JEP for details): - The "jre" subdirectory is no longer present in JDK images. - The user-editable configuration files in the "lib" subdirectory have been moved to the new "conf" directory. - The endorsed-standards override mechanism has been removed. - The extension mechanism has been removed. - rt.jar, tools.jar, and dt.jar have been removed. - A new URI scheme for naming stored modules, classes, and resources has been defined. - For tools that previously accessed rt.jar directly, a built-in NIO file-system provider has been defined to provide access to the class and resource files within a run-time image. More details are available at Mark Reinhold's latest blog entry [3] Rgds, Rory [1] http://openjdk.java.net/jeps/220 [2] https://jdk9.java.net/download/ [3] http://mreinhold.org/blog/jigsaw-modular-images -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From devopsmoreorless at gmail.com Tue Dec 9 03:50:05 2014 From: devopsmoreorless at gmail.com (Dev Ops) Date: Tue, 9 Dec 2014 09:50:05 +0100 Subject: [wildfly-dev] WildFly 9 roadmap Message-ID: Hi all, does anybody know when WildFly 9 will be released, more or less??? TIA, DevOps guy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141209/fd99ea70/attachment.html From devopsmoreorless at gmail.com Tue Dec 9 05:06:25 2014 From: devopsmoreorless at gmail.com (Dev Ops) Date: Tue, 9 Dec 2014 11:06:25 +0100 Subject: [wildfly-dev] Management console web application Message-ID: Hi all, where do I find the source of the web application which provides the Management console? I need to add something to it, but I don't know where to get the source. TIA, DevOps guy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141209/4f89d1fa/attachment.html From hpehl at redhat.com Tue Dec 9 05:13:39 2014 From: hpehl at redhat.com (Harald Pehl) Date: Tue, 9 Dec 2014 11:13:39 +0100 Subject: [wildfly-dev] Management console web application In-Reply-To: References: Message-ID: The source code for the management console lives in its own repository at https://github.com/hal/core I'm curious, what kind of customization do you have in mind? .: Harald > Am 09.12.2014 um 11:06 schrieb Dev Ops : > > Hi all, > where do I find the source of the web application which provides the Management console? > > I need to add something to it, but I don't know where to get the source. > > > TIA, > DevOps guy > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141209/d47c07c1/attachment.html From asoldano at redhat.com Tue Dec 9 06:07:34 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Tue, 09 Dec 2014 12:07:34 +0100 Subject: [wildfly-dev] Change WebServices subsystem to use PersistentResourceXMLDescription In-Reply-To: <5485BD22.1040406@redhat.com> References: <5485BD22.1040406@redhat.com> Message-ID: <5486D7F6.1060407@redhat.com> On 08/12/14 16:00, Brian Stansberry wrote: > On 12/8/14, 8:09 AM, Claudio Miranda wrote: >> >> Later I can submit it for review if is of interest. > > Look for a response from Alessio Soldano as I'd ask him to approve the > PR anyway. > > I definitely prefer attributes to text elements. I've had a brief chat with Tomaz on this topic. Frankly, I don't see any immediate benefit from these changes (perhaps the model would look a bit clearer to the final user?), while it looks like we might get some in the future. So I won't object to the changes as long as they introduce no regression. Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From devopsmoreorless at gmail.com Tue Dec 9 06:42:50 2014 From: devopsmoreorless at gmail.com (Dev Ops) Date: Tue, 9 Dec 2014 12:42:50 +0100 Subject: [wildfly-dev] Management console web application In-Reply-To: References: Message-ID: Hi, thanks for pointing me to the github repo. I need to do a couple of things: 1. provide a graphical and complete view of all server-groups - along with the hosts - something like the following http://bl.ocks.org/mbostock/1062288 2. provide a button to download the deployed application; Next would be extending point 2. by providing different colors for different metric values. Likely, heap memory metric going to saturation, the balloon would be colored has almost red (#cc0000)... every hosts could have its own metric (heap memory, cpu usage, connection pool statistics, etc...). Alerts and notifications are not needed, as there are already other software accomplishing these tasks (nagios, jon, etc...). Regards, DevOps guy On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl wrote: > The source code for the management console lives in its own repository at > https://github.com/hal/core > > I'm curious, what kind of customization do you have in mind? > > .: Harald > > Am 09.12.2014 um 11:06 schrieb Dev Ops : > > Hi all, > where do I find the source of the web application which provides the > Management console? > > I need to add something to it, but I don't know where to get the source. > > > TIA, > DevOps guy > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141209/dff8e542/attachment.html From tomaz.cerar at gmail.com Tue Dec 9 06:57:45 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 9 Dec 2014 12:57:45 +0100 Subject: [wildfly-dev] JDK 9 images are now modular with JDK 9 Early Access build 41 In-Reply-To: <5486B5C2.9080900@oracle.com> References: <5486B5C2.9080900@oracle.com> Message-ID: Hey Rory, I downloaded b41 and ran wildfly-core testsuite with it http://teamcity.cafe-babe.org/viewLog.html?buildId=10518&buildTypeId=WildFly_WildflyCore_Build&tab=buildResultsDiv and it looks great, two tests failing need fixing on our side to account for no more PermGen in Sun/Oracle jdk. -- tomaz On Tue, Dec 9, 2014 at 9:41 AM, Rory O'Donnell wrote: > > Hi Jason/Tomaz, > > > The initial changesets for JEP 220: Modular Run-Time Images [1] are > available > with JDK 9 early-access build 41 [2]. > > To summarize (please see the JEP for details): > > - The "jre" subdirectory is no longer present in JDK images. > > - The user-editable configuration files in the "lib" subdirectory > have been moved to the new "conf" directory. > > - The endorsed-standards override mechanism has been removed. > > - The extension mechanism has been removed. > > - rt.jar, tools.jar, and dt.jar have been removed. > > - A new URI scheme for naming stored modules, classes, and resources > has been defined. > > - For tools that previously accessed rt.jar directly, a built-in NIO > file-system provider has been defined to provide access to the class > and resource files within a run-time image. > > More details are available at Mark Reinhold's latest blog entry [3] > > Rgds, Rory > > [1] http://openjdk.java.net/jeps/220 > [2] https://jdk9.java.net/download/ > [3] http://mreinhold.org/blog/jigsaw-modular-images > > > > -- > 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/20141209/7dcadc09/attachment.html From rory.odonnell at oracle.com Tue Dec 9 07:01:44 2014 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 09 Dec 2014 12:01:44 +0000 Subject: [wildfly-dev] JDK 9 images are now modular with JDK 9 Early Access build 41 In-Reply-To: References: <5486B5C2.9080900@oracle.com> Message-ID: <5486E4A8.5020908@oracle.com> Thanks for that Tomaz! On 09/12/2014 11:57, Toma? Cerar wrote: > Hey Rory, > > I downloaded b41 and ran wildfly-core testsuite with it > http://teamcity.cafe-babe.org/viewLog.html?buildId=10518&buildTypeId=WildFly_WildflyCore_Build&tab=buildResultsDiv > > and it looks great, two tests failing need fixing on our side to > account for no more PermGen in Sun/Oracle jdk. > > -- > tomaz > > On Tue, Dec 9, 2014 at 9:41 AM, Rory O'Donnell > > wrote: > > > Hi Jason/Tomaz, > > > The initial changesets for JEP 220: Modular Run-Time Images [1] > are available > with JDK 9 early-access build 41 [2]. > > To summarize (please see the JEP for details): > > - The "jre" subdirectory is no longer present in JDK images. > > - The user-editable configuration files in the "lib" subdirectory > have been moved to the new "conf" directory. > > - The endorsed-standards override mechanism has been removed. > > - The extension mechanism has been removed. > > - rt.jar, tools.jar, and dt.jar have been removed. > > - A new URI scheme for naming stored modules, classes, and > resources > has been defined. > > - For tools that previously accessed rt.jar directly, a > built-in NIO > file-system provider has been defined to provide access to > the class > and resource files within a run-time image. > > More details are available at Mark Reinhold's latest blog entry [3] > > Rgds, Rory > > [1] http://openjdk.java.net/jeps/220 > [2] https://jdk9.java.net/download/ > [3] http://mreinhold.org/blog/jigsaw-modular-images > > > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -- 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/20141209/5b32ebbd/attachment-0001.html From kabir.khan at jboss.com Tue Dec 9 07:56:00 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 9 Dec 2014 13:56:00 +0100 Subject: [wildfly-dev] Change WebServices subsystem to use PersistentResourceXMLDescription In-Reply-To: <5486D7F6.1060407@redhat.com> References: <5485BD22.1040406@redhat.com> <5486D7F6.1060407@redhat.com> Message-ID: <20563EB4-F424-4F18-B37D-630E294F1840@jboss.com> > On 9 Dec 2014, at 12:07, Alessio Soldano wrote: > > On 08/12/14 16:00, Brian Stansberry wrote: >> On 12/8/14, 8:09 AM, Claudio Miranda wrote: >>> >>> Later I can submit it for review if is of interest. >> >> Look for a response from Alessio Soldano as I'd ask him to approve the >> PR anyway. >> >> I definitely prefer attributes to text elements. > > I've had a brief chat with Tomaz on this topic. Frankly, I don't see any > immediate benefit from these changes (perhaps the model would look a bit > clearer to the final user?), while it looks like we might get some in My understanding was this was the xml only. For the resource model (which I have not checked to see what is there), be careful restructuring that, since transformation to the legacy models is hard. > the future. > So I won't object to the changes as long as they introduce no regression. > Cheers > Alessio > > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Tue Dec 9 07:58:51 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 9 Dec 2014 13:58:51 +0100 Subject: [wildfly-dev] Change WebServices subsystem to use PersistentResourceXMLDescription In-Reply-To: <20563EB4-F424-4F18-B37D-630E294F1840@jboss.com> References: <5485BD22.1040406@redhat.com> <5486D7F6.1060407@redhat.com> <20563EB4-F424-4F18-B37D-630E294F1840@jboss.com> Message-ID: On Tue, Dec 9, 2014 at 1:56 PM, Kabir Khan wrote: > My understanding was this was the xml only. For the resource model (which > I have not checked to see what is there), be careful restructuring that, > since transformation to the legacy models is hard. Moving to PeristantResourceDefinition & PersistantResourceXMLDescription should not effect model structure in any way. Unless some mistake in conversion is made. If all is right, only xml format should be affected. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141209/e6c5ac4c/attachment.html From claudio at claudius.com.br Tue Dec 9 08:10:20 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Tue, 9 Dec 2014 11:10:20 -0200 Subject: [wildfly-dev] Change WebServices subsystem to use PersistentResourceXMLDescription In-Reply-To: <5486D7F6.1060407@redhat.com> References: <5485BD22.1040406@redhat.com> <5486D7F6.1060407@redhat.com> Message-ID: There are two proposed changes: 1. change subsystem implementation to use PersistentResourceXMLDescription 2. modify subsystem xml, the wsdl elements to attributes. On Tue, Dec 9, 2014 at 9:07 AM, Alessio Soldano wrote: > Frankly, I don't see any immediate benefit from these changes (perhaps the model would look a bit > clearer to the final user?), while it looks like we might get some in the future. It brings no immediate benefit for users. I saw other subsystem implementation (mail, undertow) uses PersistentResourceXMLDescription and attributes, so I thought it would be a good idea to (kind of) "modernize" webservices subsystem. This is much more a personal exercise for me to better understand subsystem implementation, if it doesn't fail the tests, would be good to PR it. Regards -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From brian.stansberry at redhat.com Tue Dec 9 09:26:57 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 09 Dec 2014 08:26:57 -0600 Subject: [wildfly-dev] Change WebServices subsystem to use PersistentResourceXMLDescription In-Reply-To: References: <5485BD22.1040406@redhat.com> <5486D7F6.1060407@redhat.com> Message-ID: <548706B1.8080302@redhat.com> On 12/9/14, 7:10 AM, Claudio Miranda wrote: > There are two proposed changes: > 1. change subsystem implementation to use PersistentResourceXMLDescription > 2. modify subsystem xml, the wsdl elements to attributes. > > On Tue, Dec 9, 2014 at 9:07 AM, Alessio Soldano wrote: >> Frankly, I don't see any immediate benefit from these changes (perhaps the model would look a bit >> clearer to the final user?), while it looks like we might get some in the future. > > It brings no immediate benefit for users. I saw other subsystem > implementation (mail, undertow) uses PersistentResourceXMLDescription > and attributes, so I thought it would be a good idea to (kind of) > "modernize" webservices subsystem. > > This is much more a personal exercise for me to better understand > subsystem implementation, if it doesn't fail the tests, would be good > to PR it. > My only other comment on this is the xml style should be consistent across the entire subsystem, so if this is only for a part (I'm too lazy to look) then that's not good. But I support the idea of moving to this style in general. Attributes instead of text elements is much more 'standard' for the WildFly config files. And I expect things will keep moving that way, so stuff that doesn't will seem more and more "non-standard". -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From claudio at claudius.com.br Tue Dec 9 11:59:00 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Tue, 9 Dec 2014 14:59:00 -0200 Subject: [wildfly-dev] Change WebServices subsystem to use PersistentResourceXMLDescription In-Reply-To: <548706B1.8080302@redhat.com> References: <5485BD22.1040406@redhat.com> <5486D7F6.1060407@redhat.com> <548706B1.8080302@redhat.com> Message-ID: On Tue, Dec 9, 2014 at 12:26 PM, Brian Stansberry wrote: > My only other comment on this is the xml style should be consistent across > the entire subsystem, so if this is only for a part (I'm too lazy to look) > then that's not good. The other parts of WS subsystem are already attributes. > But I support the idea of moving to this style in general. Attributes > instead of text elements is much more 'standard' for the WildFly config > files. And I expect things will keep moving that way, so stuff that doesn't > will seem more and more "non-standard". That is my thought, to let WS subsystem more like the others, attribute based. -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From brian.stansberry at redhat.com Tue Dec 9 15:00:21 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 09 Dec 2014 14:00:21 -0600 Subject: [wildfly-dev] Management model attribute groups Message-ID: <548754D5.9090402@redhat.com> Off and on we've had discussions around the idea of "attribute groups". We've got some use cases that are crying out for such a thing[1], so I'd like to propose doing something concrete but simple for these for WF 9, ideally in the next month. A big part of my goal here is to ensure that whatever we do doesn't preclude something more advanced in any next generation management stuff, e.g. David's stuff. PART I Concepts 1) What is an attribute group? The "attribute group" concept I propose is simply a collection of attributes associated with the same resource type that are independently configurable but are statically declared to be conceptually related. The group has a name, and members. The name provides a brief indication of the nature of the relationship. The goal is to provide information to the user to help them better understand the relationship between attributes. In particular, management tools could use this information to visually present related attributes together, e.g. in a tab or other grouping widget in the web console. 2) What isn't an attribute group? Something relevant to writes. 3) Why would I use a child resource instead of an attribute group? Because the attributes control a discrete piece of functionality and you need to be able to turn that on or off as a unit. So you add/remove the resource. 4) Why would I use a complex attribute with a bunch of fields instead of n>1 simple attributes in a group. a) Because the attributes control a discrete piece of functionality and you need to be able to turn that off as a unit. So users can undefine the complex attribute. b) Because it's a common use case that modifications to n>1 of the fields should be done atomically and you don't want to force users to use a CLI batch. So you let them use write-attribute and specify the value of all the fields. 5) Why would I use an attribute group instead of a child resource? Because requiring users to add a child resource just to set a bunch of values that are really part of the config of the parent resource forces them to use a CLI batch to correctly configure the parent resource. 6) Why would I use an attribute group instead a complex attribute? Because the various attributes should be independently configurable. In particular, wiping out the config for all of them by simply undefining the complex attribute isn't appropriate. PART II Proposed Work 1) The basics We add a piece of metadata to the read-resource-description output for an attribute. Name is 'attribute-group', value type is ModelType.STRING, value is the name of the group, with 'undefined' allowed. The group is simply the set of attributes that share the same string. To implement this, we add public String AttributeDefinition.getAttributeGroup() and add support for setting it to the relevant Builder. ReadResourceDescriptionHandler outputs the value. 2) XML parsing/marshalling Modify PersistentResourceXMLDescription such that attributes in an attribute group get persisted in their own child element, whose name is the name of the group. PersistentResourceXMLBuilder exposes a setter to allow users to turn this on/off for that resource. Turning it off will allow the addition of attribute group settings for a resource without requiring an immediate corresponding xsd change. 3) Web console HAL can make use of the additional metadata at its leisure, and as it becomes available. 4) Low level management API The output of read-resource and read-resource-description is modified such that attributes are sorted by group name and then by attribute name. 5) CLI I'm not clear on exactly what to do here, but my instinct is the output of the 'ls -l' command should be modified. Probably add a GROUP column to the right and sort the order of attributes by group and then by attribute name. PART III Other possible things to do A :read-attribute-group(name=) operation or an "attribute-groups=[*]" param to :read-resource, to make it convenient to read a set of attributes without needing to read the entire resource. We could also consider adding an "attribute-groups" section to the read-resource-description output, where a fuller i18n text description of the meaning of the group could be written. If we do this we should probably do it in WF 9 as it will likely add some sort of requirement to subsystem authors that we expose right from the start. If you're still awake, comments as always are appreciated. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat [1] For example, the JDKORB pull request at https://github.com/wildfly/wildfly/pull/7008 uses child resources in a number of places where it seems like attribute groups are a better fit. From jason.greene at redhat.com Tue Dec 9 17:41:56 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 9 Dec 2014 16:41:56 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <548754D5.9090402@redhat.com> References: <548754D5.9090402@redhat.com> Message-ID: <4BE8D3CE-356A-4CB8-BBDD-BAD655D6D168@redhat.com> This proposal is a great idea. Let?s do it :) > On Dec 9, 2014, at 2:00 PM, Brian Stansberry wrote: > > Off and on we've had discussions around the idea of "attribute groups". > We've got some use cases that are crying out for such a thing[1], so I'd > like to propose doing something concrete but simple for these for WF 9, > ideally in the next month. > > A big part of my goal here is to ensure that whatever we do doesn't > preclude something more advanced in any next generation management > stuff, e.g. David's stuff. > > PART I Concepts > > 1) What is an attribute group? > > The "attribute group" concept I propose is simply a collection of > attributes associated with the same resource type that are independently > configurable but are statically declared to be conceptually related. The > group has a name, and members. The name provides a brief indication of > the nature of the relationship. > > The goal is to provide information to the user to help them better > understand the relationship between attributes. In particular, > management tools could use this information to visually present related > attributes together, e.g. in a tab or other grouping widget in the web > console. > > 2) What isn't an attribute group? > > Something relevant to writes. > > 3) Why would I use a child resource instead of an attribute group? > > Because the attributes control a discrete piece of functionality and you > need to be able to turn that on or off as a unit. So you add/remove the > resource. > > 4) Why would I use a complex attribute with a bunch of fields instead of > n>1 simple attributes in a group. > > a) Because the attributes control a discrete piece of functionality and > you need to be able to turn that off as a unit. So users can undefine > the complex attribute. > > b) Because it's a common use case that modifications to n>1 of the > fields should be done atomically and you don't want to force users to > use a CLI batch. So you let them use write-attribute and specify the > value of all the fields. > > 5) Why would I use an attribute group instead of a child resource? > > Because requiring users to add a child resource just to set a bunch of > values that are really part of the config of the parent resource forces > them to use a CLI batch to correctly configure the parent resource. > > 6) Why would I use an attribute group instead a complex attribute? > > Because the various attributes should be independently configurable. In > particular, wiping out the config for all of them by simply undefining > the complex attribute isn't appropriate. > > PART II Proposed Work > > 1) The basics > > We add a piece of metadata to the read-resource-description output for > an attribute. Name is 'attribute-group', value type is ModelType.STRING, > value is the name of the group, with 'undefined' allowed. > > The group is simply the set of attributes that share the same string. > > To implement this, we add public String > AttributeDefinition.getAttributeGroup() and add support for setting it > to the relevant Builder. ReadResourceDescriptionHandler outputs the value. > > 2) XML parsing/marshalling > > Modify PersistentResourceXMLDescription such that attributes in an > attribute group get persisted in their own child element, whose name is > the name of the group. > > PersistentResourceXMLBuilder exposes a setter to allow users to turn > this on/off for that resource. Turning it off will allow the addition of > attribute group settings for a resource without requiring an immediate > corresponding xsd change. > > 3) Web console > > HAL can make use of the additional metadata at its leisure, and as it > becomes available. > > 4) Low level management API > > The output of read-resource and read-resource-description is modified > such that attributes are sorted by group name and then by attribute name. > > 5) CLI > > I'm not clear on exactly what to do here, but my instinct is the output > of the 'ls -l' command should be modified. Probably add a GROUP column > to the right and sort the order of attributes by group and then by > attribute name. > > PART III Other possible things to do > > A :read-attribute-group(name=) operation or an > "attribute-groups=[*]" param to :read-resource, to make it > convenient to read a set of attributes without needing to read the > entire resource. > > We could also consider adding an "attribute-groups" section to the > read-resource-description output, where a fuller i18n text description > of the meaning of the group could be written. If we do this we should > probably do it in WF 9 as it will likely add some sort of requirement to > subsystem authors that we expose right from the start. > > > If you're still awake, comments as always are appreciated. > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > > [1] For example, the JDKORB pull request at > https://github.com/wildfly/wildfly/pull/7008 uses child resources in a > number of places where it seems like attribute groups are a better fit. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From hbraun at redhat.com Wed Dec 10 02:04:32 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 10 Dec 2014 08:04:32 +0100 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <548754D5.9090402@redhat.com> References: <548754D5.9090402@redhat.com> Message-ID: <20327C4E-CBE3-4B4A-B678-38670E73138C@redhat.com> +1 i am all for it. Including read-attribute-group(). But i would as well add a read-attribute-group-names() operation to complete the picture. > Am 09.12.2014 um 21:00 schrieb Brian Stansberry : > > read-attribute-group From lfugaro at redhat.com Wed Dec 10 02:51:48 2014 From: lfugaro at redhat.com (Luigi Fugaro) Date: Wed, 10 Dec 2014 02:51:48 -0500 (EST) Subject: [wildfly-dev] WildFly 9 roadmap In-Reply-To: References: Message-ID: Probably someday around Spring 2015... Inviato da iPad-Mini > Il giorno 09/dic/2014, alle ore 09:50, Dev Ops ha scritto: > > Hi all, > does anybody know when WildFly 9 will be released, more or less??? > > TIA, > DevOps guy > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From lfugaro at redhat.com Wed Dec 10 02:53:50 2014 From: lfugaro at redhat.com (Luigi Fugaro) Date: Wed, 10 Dec 2014 02:53:50 -0500 (EST) Subject: [wildfly-dev] Management console web application In-Reply-To: References: Message-ID: <69792B9F-6D9F-49D1-86CC-0D3E4520829F@redhat.com> Inviato da iPad-Mini > Il giorno 09/dic/2014, alle ore 12:43, Dev Ops ha scritto: > > Hi, > thanks for pointing me to the github repo. > > I need to do a couple of things: > provide a graphical and complete view of all server-groups - along with the hosts - something like the following http://bl.ocks.org/mbostock/1062288 > provide a button to download the deployed application; > Next would be extending point 2. by providing different colors for different metric values. > Likely, heap memory metric going to saturation, the balloon would be colored has almost red (#cc0000)... every hosts could have its own metric (heap memory, cpu usage, connection pool statistics, etc...). > Alerts and notifications are not needed, as there are already other software accomplishing these tasks (nagios, jon, etc...). > I guess you were referring to point 1. > Regards, > DevOps guy > > >> On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl wrote: >> The source code for the management console lives in its own repository at https://github.com/hal/core >> >> I'm curious, what kind of customization do you have in mind? >> >> .: Harald >> >>> Am 09.12.2014 um 11:06 schrieb Dev Ops : >>> >>> Hi all, >>> where do I find the source of the web application which provides the Management console? >>> >>> I need to add something to it, but I don't know where to get the source. >>> >>> >>> TIA, >>> DevOps guy >>> _______________________________________________ >>> 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/20141210/47d70ae5/attachment.html From hpehl at redhat.com Wed Dec 10 04:58:50 2014 From: hpehl at redhat.com (Harald Pehl) Date: Wed, 10 Dec 2014 10:58:50 +0100 Subject: [wildfly-dev] Management console web application In-Reply-To: References: Message-ID: > > Am 09.12.2014 um 12:42 schrieb Dev Ops : > > Hi, > thanks for pointing me to the github repo. > > I need to do a couple of things: > provide a graphical and complete view of all server-groups - along with the hosts - something like the following http://bl.ocks.org/mbostock/1062288 That's something we've always wanted to have in the console. Currently the console has some weak points when it comes to manage big domains with lots of hosts and servers. Some kind of bird's-eye view for big topologies would definitely be an improvement. > provide a button to download the deployed application; Not sure what's the use case behind that. Maybe you can elaborate more on that. > Next would be extending point 2. by providing different colors for different metric values. > Likely, heap memory metric going to saturation, the balloon would be colored has almost red (#cc0000)... every hosts could have its own metric (heap memory, cpu usage, connection pool statistics, etc...). > Alerts and notifications are not needed, as there are already other software accomplishing these tasks (nagios, jon, etc...). > > Regards, > DevOps guy Any contributions which address these enhancements are highly welcome! The management console is implemented in GWT. There's some documentation about the internals and how to get started at [1]. You can ping me anytime on #wildfly-management if you need more details or to discuss the next steps. [1] http://hal.github.io/ .: Harald > > > On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl > wrote: > The source code for the management console lives in its own repository at https://github.com/hal/core > > I'm curious, what kind of customization do you have in mind? > > .: Harald > >> Am 09.12.2014 um 11:06 schrieb Dev Ops >: >> >> Hi all, >> where do I find the source of the web application which provides the Management console? >> >> I need to add something to it, but I don't know where to get the source. >> >> >> TIA, >> DevOps guy >> _______________________________________________ >> 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 > > --- Harald Pehl JBoss by Red Hat http://hpehl.info -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141210/736faa83/attachment.html From ehugonne at redhat.com Wed Dec 10 04:59:55 2014 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Wed, 10 Dec 2014 10:59:55 +0100 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <548754D5.9090402@redhat.com> References: <548754D5.9090402@redhat.com> Message-ID: <5488199B.8010608@redhat.com> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ? Is aliasing to be supported ? What if I want to change the attribute group name ? Emmanuel Le 09/12/2014 21:00, Brian Stansberry a ?crit : > Off and on we've had discussions around the idea of "attribute groups". > We've got some use cases that are crying out for such a thing[1], so I'd > like to propose doing something concrete but simple for these for WF 9, > ideally in the next month. > > A big part of my goal here is to ensure that whatever we do doesn't > preclude something more advanced in any next generation management > stuff, e.g. David's stuff. > > PART I Concepts > > 1) What is an attribute group? > > The "attribute group" concept I propose is simply a collection of > attributes associated with the same resource type that are independently > configurable but are statically declared to be conceptually related. The > group has a name, and members. The name provides a brief indication of > the nature of the relationship. > > The goal is to provide information to the user to help them better > understand the relationship between attributes. In particular, > management tools could use this information to visually present related > attributes together, e.g. in a tab or other grouping widget in the web > console. > > 2) What isn't an attribute group? > > Something relevant to writes. > > 3) Why would I use a child resource instead of an attribute group? > > Because the attributes control a discrete piece of functionality and you > need to be able to turn that on or off as a unit. So you add/remove the > resource. > > 4) Why would I use a complex attribute with a bunch of fields instead of > n>1 simple attributes in a group. > > a) Because the attributes control a discrete piece of functionality and > you need to be able to turn that off as a unit. So users can undefine > the complex attribute. > > b) Because it's a common use case that modifications to n>1 of the > fields should be done atomically and you don't want to force users to > use a CLI batch. So you let them use write-attribute and specify the > value of all the fields. > > 5) Why would I use an attribute group instead of a child resource? > > Because requiring users to add a child resource just to set a bunch of > values that are really part of the config of the parent resource forces > them to use a CLI batch to correctly configure the parent resource. > > 6) Why would I use an attribute group instead a complex attribute? > > Because the various attributes should be independently configurable. In > particular, wiping out the config for all of them by simply undefining > the complex attribute isn't appropriate. > > PART II Proposed Work > > 1) The basics > > We add a piece of metadata to the read-resource-description output for > an attribute. Name is 'attribute-group', value type is ModelType.STRING, > value is the name of the group, with 'undefined' allowed. > > The group is simply the set of attributes that share the same string. > > To implement this, we add public String > AttributeDefinition.getAttributeGroup() and add support for setting it > to the relevant Builder. ReadResourceDescriptionHandler outputs the value. > > 2) XML parsing/marshalling > > Modify PersistentResourceXMLDescription such that attributes in an > attribute group get persisted in their own child element, whose name is > the name of the group. > > PersistentResourceXMLBuilder exposes a setter to allow users to turn > this on/off for that resource. Turning it off will allow the addition of > attribute group settings for a resource without requiring an immediate > corresponding xsd change. > > 3) Web console > > HAL can make use of the additional metadata at its leisure, and as it > becomes available. > > 4) Low level management API > > The output of read-resource and read-resource-description is modified > such that attributes are sorted by group name and then by attribute name. > > 5) CLI > > I'm not clear on exactly what to do here, but my instinct is the output > of the 'ls -l' command should be modified. Probably add a GROUP column > to the right and sort the order of attributes by group and then by > attribute name. > > PART III Other possible things to do > > A :read-attribute-group(name=) operation or an > "attribute-groups=[*]" param to :read-resource, to make it > convenient to read a set of attributes without needing to read the > entire resource. > > We could also consider adding an "attribute-groups" section to the > read-resource-description output, where a fuller i18n text description > of the meaning of the group could be written. If we do this we should > probably do it in WF 9 as it will likely add some sort of requirement to > subsystem authors that we expose right from the start. > > > If you're still awake, comments as always are appreciated. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141210/83cb12b3/attachment-0001.bin From devopsmoreorless at gmail.com Wed Dec 10 06:14:58 2014 From: devopsmoreorless at gmail.com (Dev Ops) Date: Wed, 10 Dec 2014 12:14:58 +0100 Subject: [wildfly-dev] Management console web application In-Reply-To: References: Message-ID: On Wed, Dec 10, 2014 at 10:58 AM, Harald Pehl wrote: > > Am 09.12.2014 um 12:42 schrieb Dev Ops : > > Hi, > thanks for pointing me to the github repo. > > I need to do a couple of things: > > 1. provide a graphical and complete view of all server-groups - along > with the hosts - something like the following > http://bl.ocks.org/mbostock/1062288 > > That's something we've always wanted to have in the console. Currently the > console has some weak points when it comes to manage big domains with lots > of hosts and servers. Some kind of bird's-eye view for big topologies would > definitely be an improvement. > > > 1. provide a button to download the deployed application; > > Not sure what's the use case behind that. Maybe you can elaborate more on > that. > Most of the time I "operate" in environments and situation where there is NOT an artifact repository. People merely know the existence of words like CI, CD and so on, thus before upgrading a web-application they need to back it up. Having a button next to the application can be handy. > Next would be extending point 2. by providing different colors for > different metric values. > Likely, heap memory metric going to saturation, the balloon would be > colored has almost red (#cc0000)... every hosts could have its own metric > (heap memory, cpu usage, connection pool statistics, etc...). > Alerts and notifications are not needed, as there are already other > software accomplishing these tasks (nagios, jon, etc...). > Regards, > DevOps guy > > > Any contributions which address these enhancements are highly welcome! The > management console is implemented in GWT. There's some documentation about > the internals and how to get started at [1]. You can ping me anytime on > #wildfly-management if you need more details or to discuss the next steps. > > [1] http://hal.github.io/ > > .: Harald > > > > On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl wrote: > >> The source code for the management console lives in its own repository at >> https://github.com/hal/core >> >> I'm curious, what kind of customization do you have in mind? >> >> .: Harald >> >> Am 09.12.2014 um 11:06 schrieb Dev Ops : >> >> Hi all, >> where do I find the source of the web application which provides the >> Management console? >> >> I need to add something to it, but I don't know where to get the source. >> >> >> TIA, >> DevOps guy >> _______________________________________________ >> 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 >> >> > > --- > Harald Pehl > JBoss by Red Hat > http://hpehl.info > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141210/296fc7d4/attachment.html From hbraun at redhat.com Wed Dec 10 07:26:23 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 10 Dec 2014 13:26:23 +0100 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488199B.8010608@redhat.com> References: <548754D5.9090402@redhat.com> <5488199B.8010608@redhat.com> Message-ID: <862B2D74-B50D-4A71-805D-FBDF707C0C6D@redhat.com> Changing group names is not user space Api. Users can map internal names to custom titles, if needed. > Am 10.12.2014 um 10:59 schrieb Emmanuel Hugonnet : > > Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ? > Is aliasing to be supported ? What if I want to change the attribute group name ? > > Emmanuel > > > Le 09/12/2014 21:00, Brian Stansberry a ?crit : >> Off and on we've had discussions around the idea of "attribute groups". >> We've got some use cases that are crying out for such a thing[1], so I'd >> like to propose doing something concrete but simple for these for WF 9, >> ideally in the next month. >> >> A big part of my goal here is to ensure that whatever we do doesn't >> preclude something more advanced in any next generation management >> stuff, e.g. David's stuff. >> >> PART I Concepts >> >> 1) What is an attribute group? >> >> The "attribute group" concept I propose is simply a collection of >> attributes associated with the same resource type that are independently >> configurable but are statically declared to be conceptually related. The >> group has a name, and members. The name provides a brief indication of >> the nature of the relationship. >> >> The goal is to provide information to the user to help them better >> understand the relationship between attributes. In particular, >> management tools could use this information to visually present related >> attributes together, e.g. in a tab or other grouping widget in the web >> console. >> >> 2) What isn't an attribute group? >> >> Something relevant to writes. >> >> 3) Why would I use a child resource instead of an attribute group? >> >> Because the attributes control a discrete piece of functionality and you >> need to be able to turn that on or off as a unit. So you add/remove the >> resource. >> >> 4) Why would I use a complex attribute with a bunch of fields instead of >> n>1 simple attributes in a group. >> >> a) Because the attributes control a discrete piece of functionality and >> you need to be able to turn that off as a unit. So users can undefine >> the complex attribute. >> >> b) Because it's a common use case that modifications to n>1 of the >> fields should be done atomically and you don't want to force users to >> use a CLI batch. So you let them use write-attribute and specify the >> value of all the fields. >> >> 5) Why would I use an attribute group instead of a child resource? >> >> Because requiring users to add a child resource just to set a bunch of >> values that are really part of the config of the parent resource forces >> them to use a CLI batch to correctly configure the parent resource. >> >> 6) Why would I use an attribute group instead a complex attribute? >> >> Because the various attributes should be independently configurable. In >> particular, wiping out the config for all of them by simply undefining >> the complex attribute isn't appropriate. >> >> PART II Proposed Work >> >> 1) The basics >> >> We add a piece of metadata to the read-resource-description output for >> an attribute. Name is 'attribute-group', value type is ModelType.STRING, >> value is the name of the group, with 'undefined' allowed. >> >> The group is simply the set of attributes that share the same string. >> >> To implement this, we add public String >> AttributeDefinition.getAttributeGroup() and add support for setting it >> to the relevant Builder. ReadResourceDescriptionHandler outputs the value. >> >> 2) XML parsing/marshalling >> >> Modify PersistentResourceXMLDescription such that attributes in an >> attribute group get persisted in their own child element, whose name is >> the name of the group. >> >> PersistentResourceXMLBuilder exposes a setter to allow users to turn >> this on/off for that resource. Turning it off will allow the addition of >> attribute group settings for a resource without requiring an immediate >> corresponding xsd change. >> >> 3) Web console >> >> HAL can make use of the additional metadata at its leisure, and as it >> becomes available. >> >> 4) Low level management API >> >> The output of read-resource and read-resource-description is modified >> such that attributes are sorted by group name and then by attribute name. >> >> 5) CLI >> >> I'm not clear on exactly what to do here, but my instinct is the output >> of the 'ls -l' command should be modified. Probably add a GROUP column >> to the right and sort the order of attributes by group and then by >> attribute name. >> >> PART III Other possible things to do >> >> A :read-attribute-group(name=) operation or an >> "attribute-groups=[*]" param to :read-resource, to make it >> convenient to read a set of attributes without needing to read the >> entire resource. >> >> We could also consider adding an "attribute-groups" section to the >> read-resource-description output, where a fuller i18n text description >> of the meaning of the group could be written. If we do this we should >> probably do it in WF 9 as it will likely add some sort of requirement to >> subsystem authors that we expose right from the start. >> >> >> If you're still awake, comments as always are appreciated. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Wed Dec 10 09:21:33 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 08:21:33 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488199B.8010608@redhat.com> References: <548754D5.9090402@redhat.com> <5488199B.8010608@redhat.com> Message-ID: <548856ED.9010809@redhat.com> On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote: > Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ? This is what I meant by "4) Low level management API The output of read-resource and read-resource-description is modified such that attributes are sorted by group name and then by attribute name." I used the verb "sorted" though because I have no intent of modifying the output structure by creating a level for the attribute group. That would be an incompatible change in the output format and would obscure the distinction between an attribute group and a complex attribute. > Is aliasing to be supported ? What if I want to change the attribute group name ? > Good question. Heiko, I don't think Emmanuel is talking about users changing this. We use aliasing in other contexts as a mechanism for maintaining compatibility. If something is poorly named (e.g. a bad resource address name) we can fix it in a later release but also register an alias under the old name to provide compatibility. I don't see how aliasing could work here. Only thing I can imagine is using it in the ls -l output, such that the same attribute can appear > 1 times, if it is associated with more than 1 group. I suppose a console could do a similar thing, but I don't at all regard maintaining that kind of compatibility in UI layout to be a requirement. I'm not sure how much we regard consistency in the ls -l output across releases as being a requirement. I think of that as being an output format for humans, not machines. Aliasing is an example of a reason for allowing an attribute to belong to more than one group. There may be others. Perhaps as an aid to querying? > Emmanuel > > > Le 09/12/2014 21:00, Brian Stansberry a ?crit : >> Off and on we've had discussions around the idea of "attribute groups". >> We've got some use cases that are crying out for such a thing[1], so I'd >> like to propose doing something concrete but simple for these for WF 9, >> ideally in the next month. >> >> A big part of my goal here is to ensure that whatever we do doesn't >> preclude something more advanced in any next generation management >> stuff, e.g. David's stuff. >> >> PART I Concepts >> >> 1) What is an attribute group? >> >> The "attribute group" concept I propose is simply a collection of >> attributes associated with the same resource type that are independently >> configurable but are statically declared to be conceptually related. The >> group has a name, and members. The name provides a brief indication of >> the nature of the relationship. >> >> The goal is to provide information to the user to help them better >> understand the relationship between attributes. In particular, >> management tools could use this information to visually present related >> attributes together, e.g. in a tab or other grouping widget in the web >> console. >> >> 2) What isn't an attribute group? >> >> Something relevant to writes. >> >> 3) Why would I use a child resource instead of an attribute group? >> >> Because the attributes control a discrete piece of functionality and you >> need to be able to turn that on or off as a unit. So you add/remove the >> resource. >> >> 4) Why would I use a complex attribute with a bunch of fields instead of >> n>1 simple attributes in a group. >> >> a) Because the attributes control a discrete piece of functionality and >> you need to be able to turn that off as a unit. So users can undefine >> the complex attribute. >> >> b) Because it's a common use case that modifications to n>1 of the >> fields should be done atomically and you don't want to force users to >> use a CLI batch. So you let them use write-attribute and specify the >> value of all the fields. >> >> 5) Why would I use an attribute group instead of a child resource? >> >> Because requiring users to add a child resource just to set a bunch of >> values that are really part of the config of the parent resource forces >> them to use a CLI batch to correctly configure the parent resource. >> >> 6) Why would I use an attribute group instead a complex attribute? >> >> Because the various attributes should be independently configurable. In >> particular, wiping out the config for all of them by simply undefining >> the complex attribute isn't appropriate. >> >> PART II Proposed Work >> >> 1) The basics >> >> We add a piece of metadata to the read-resource-description output for >> an attribute. Name is 'attribute-group', value type is ModelType.STRING, >> value is the name of the group, with 'undefined' allowed. >> >> The group is simply the set of attributes that share the same string. >> >> To implement this, we add public String >> AttributeDefinition.getAttributeGroup() and add support for setting it >> to the relevant Builder. ReadResourceDescriptionHandler outputs the value. >> >> 2) XML parsing/marshalling >> >> Modify PersistentResourceXMLDescription such that attributes in an >> attribute group get persisted in their own child element, whose name is >> the name of the group. >> >> PersistentResourceXMLBuilder exposes a setter to allow users to turn >> this on/off for that resource. Turning it off will allow the addition of >> attribute group settings for a resource without requiring an immediate >> corresponding xsd change. >> >> 3) Web console >> >> HAL can make use of the additional metadata at its leisure, and as it >> becomes available. >> >> 4) Low level management API >> >> The output of read-resource and read-resource-description is modified >> such that attributes are sorted by group name and then by attribute name. >> >> 5) CLI >> >> I'm not clear on exactly what to do here, but my instinct is the output >> of the 'ls -l' command should be modified. Probably add a GROUP column >> to the right and sort the order of attributes by group and then by >> attribute name. >> >> PART III Other possible things to do >> >> A :read-attribute-group(name=) operation or an >> "attribute-groups=[*]" param to :read-resource, to make it >> convenient to read a set of attributes without needing to read the >> entire resource. >> >> We could also consider adding an "attribute-groups" section to the >> read-resource-description output, where a fuller i18n text description >> of the meaning of the group could be written. If we do this we should >> probably do it in WF 9 as it will likely add some sort of requirement to >> subsystem authors that we expose right from the start. >> >> >> If you're still awake, comments as always are appreciated. >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From tomaz.cerar at gmail.com Wed Dec 10 09:23:07 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 10 Dec 2014 15:23:07 +0100 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <548754D5.9090402@redhat.com> References: <548754D5.9090402@redhat.com> Message-ID: On Tue, Dec 9, 2014 at 9:00 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > 5) Why would I use an attribute group instead of a child resource? > > Because requiring users to add a child resource just to set a bunch of > values that are really part of the config of the parent resource forces > them to use a CLI batch to correctly configure the parent resource. > One thing that I am not sure about this is, how do we do validation for things like this? Simple example would be "required" validation for attribute group. You want to enforce few attributes that are part of the group to be required. but on other hand you don't want to enforce them as part of resource:add operation. as they are only "required" when you are editing / adding attribute group. With current code we enforce required for all attributes on a resource that is being added. Which is bit inconvenient for when we have attribute groups and want to do it bit differently. So question is should we support selective validation based on groups or not? -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141210/0cbd6a2a/attachment-0001.html From brian.stansberry at redhat.com Wed Dec 10 09:29:17 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 08:29:17 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <4BE8D3CE-356A-4CB8-BBDD-BAD655D6D168@redhat.com> References: <548754D5.9090402@redhat.com> <4BE8D3CE-356A-4CB8-BBDD-BAD655D6D168@redhat.com> Message-ID: <548858BD.1050901@redhat.com> On 12/9/14, 4:41 PM, Jason Greene wrote: > This proposal is a great idea. Let?s do it :) > I can probably have a branch with the "Proposed Work" bit, excluding the CLI ls -l thing, done today or tomorrow. It went quicker than I thought. But the more important part is any discussion here. The CLI ls -l thing I don't want to code yet because I don't have a strong feeling about that solution. >> On Dec 9, 2014, at 2:00 PM, Brian Stansberry wrote: >> >> Off and on we've had discussions around the idea of "attribute groups". >> We've got some use cases that are crying out for such a thing[1], so I'd >> like to propose doing something concrete but simple for these for WF 9, >> ideally in the next month. >> >> A big part of my goal here is to ensure that whatever we do doesn't >> preclude something more advanced in any next generation management >> stuff, e.g. David's stuff. >> >> PART I Concepts >> >> 1) What is an attribute group? >> >> The "attribute group" concept I propose is simply a collection of >> attributes associated with the same resource type that are independently >> configurable but are statically declared to be conceptually related. The >> group has a name, and members. The name provides a brief indication of >> the nature of the relationship. >> >> The goal is to provide information to the user to help them better >> understand the relationship between attributes. In particular, >> management tools could use this information to visually present related >> attributes together, e.g. in a tab or other grouping widget in the web >> console. >> >> 2) What isn't an attribute group? >> >> Something relevant to writes. >> >> 3) Why would I use a child resource instead of an attribute group? >> >> Because the attributes control a discrete piece of functionality and you >> need to be able to turn that on or off as a unit. So you add/remove the >> resource. >> >> 4) Why would I use a complex attribute with a bunch of fields instead of >> n>1 simple attributes in a group. >> >> a) Because the attributes control a discrete piece of functionality and >> you need to be able to turn that off as a unit. So users can undefine >> the complex attribute. >> >> b) Because it's a common use case that modifications to n>1 of the >> fields should be done atomically and you don't want to force users to >> use a CLI batch. So you let them use write-attribute and specify the >> value of all the fields. >> >> 5) Why would I use an attribute group instead of a child resource? >> >> Because requiring users to add a child resource just to set a bunch of >> values that are really part of the config of the parent resource forces >> them to use a CLI batch to correctly configure the parent resource. >> >> 6) Why would I use an attribute group instead a complex attribute? >> >> Because the various attributes should be independently configurable. In >> particular, wiping out the config for all of them by simply undefining >> the complex attribute isn't appropriate. >> >> PART II Proposed Work >> >> 1) The basics >> >> We add a piece of metadata to the read-resource-description output for >> an attribute. Name is 'attribute-group', value type is ModelType.STRING, >> value is the name of the group, with 'undefined' allowed. >> >> The group is simply the set of attributes that share the same string. >> >> To implement this, we add public String >> AttributeDefinition.getAttributeGroup() and add support for setting it >> to the relevant Builder. ReadResourceDescriptionHandler outputs the value. >> >> 2) XML parsing/marshalling >> >> Modify PersistentResourceXMLDescription such that attributes in an >> attribute group get persisted in their own child element, whose name is >> the name of the group. >> >> PersistentResourceXMLBuilder exposes a setter to allow users to turn >> this on/off for that resource. Turning it off will allow the addition of >> attribute group settings for a resource without requiring an immediate >> corresponding xsd change. >> >> 3) Web console >> >> HAL can make use of the additional metadata at its leisure, and as it >> becomes available. >> >> 4) Low level management API >> >> The output of read-resource and read-resource-description is modified >> such that attributes are sorted by group name and then by attribute name. >> >> 5) CLI >> >> I'm not clear on exactly what to do here, but my instinct is the output >> of the 'ls -l' command should be modified. Probably add a GROUP column >> to the right and sort the order of attributes by group and then by >> attribute name. >> >> PART III Other possible things to do >> >> A :read-attribute-group(name=) operation or an >> "attribute-groups=[*]" param to :read-resource, to make it >> convenient to read a set of attributes without needing to read the >> entire resource. >> >> We could also consider adding an "attribute-groups" section to the >> read-resource-description output, where a fuller i18n text description >> of the meaning of the group could be written. If we do this we should >> probably do it in WF 9 as it will likely add some sort of requirement to >> subsystem authors that we expose right from the start. >> >> >> If you're still awake, comments as always are appreciated. >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> >> [1] For example, the JDKORB pull request at >> https://github.com/wildfly/wildfly/pull/7008 uses child resources in a >> number of places where it seems like attribute groups are a better fit. >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 09:37:55 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 08:37:55 -0600 Subject: [wildfly-dev] Management console web application In-Reply-To: References: Message-ID: <54885AC3.1070907@redhat.com> On 12/10/14, 5:14 AM, Dev Ops wrote: > > > On Wed, Dec 10, 2014 at 10:58 AM, Harald Pehl > wrote: > >> >> Am 09.12.2014 um 12:42 schrieb Dev Ops > >: >> >> Hi, >> thanks for pointing me to the github repo. >> >> I need to do a couple of things: >> >> 1. provide a graphical and complete view of all server-groups - >> along with the hosts - something like the following >> http://bl.ocks.org/mbostock/1062288 > That's something we've always wanted to have in the console. > Currently the console has some weak points when it comes to manage > big domains with lots of hosts and servers. Some kind of bird's-eye > view for big topologies would definitely be an improvement. >> >> 2. provide a button to download the deployed application; > Not sure what's the use case behind that. Maybe you can elaborate > more on that. > > > Most of the time I "operate" in environments and situation where there > is NOT an artifact repository. > People merely know the existence of words like CI, CD and so on, thus > before upgrading a web-application they need to back it up. > Having a button next to the application can be handy. > Supporting this would require some server-side functionality, as we don't expose the content in the content repository via the management API. It would probably be pretty simple to do though, using the attach-a-stream-to-a-response thing we've added in 9. Used now by the log download feature. > >> Next would be extending point 2. by providing different colors for >> different metric values. >> Likely, heap memory metric going to saturation, the balloon would >> be colored has almost red (#cc0000)... every hosts could have its >> own metric (heap memory, cpu usage, connection pool statistics, >> etc...). >> Alerts and notifications are not needed, as there are already >> other software accomplishing these tasks (nagios, jon, etc...). >> >> Regards, >> DevOps guy > > Any contributions which address these enhancements are highly > welcome! The management console is implemented in GWT. There's some > documentation about the internals and how to get started at [1]. You > can ping me anytime on #wildfly-management if you need more details > or to discuss the next steps. > > [1] http://hal.github.io/ > > .: Harald > >> >> >> On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl > > wrote: >> >> The source code for the management console lives in its own >> repository at https://github.com/hal/core >> >> I'm curious, what kind of customization do you have in mind? >> >> .: Harald >> >>> Am 09.12.2014 um 11:06 schrieb Dev Ops >>> >: >>> >>> Hi all, >>> where do I find the source of the web application which >>> provides the Management console? >>> >>> I need to add something to it, but I don't know where to get >>> the source. >>> >>> >>> TIA, >>> DevOps guy >>> _______________________________________________ >>> 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 >> >> > > --- > 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 Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 09:45:13 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 08:45:13 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: References: <548754D5.9090402@redhat.com> Message-ID: <54885C79.9070705@redhat.com> On 12/10/14, 8:23 AM, Toma? Cerar wrote: > > On Tue, Dec 9, 2014 at 9:00 PM, Brian Stansberry > > wrote: > > 5) Why would I use an attribute group instead of a child resource? > > Because requiring users to add a child resource just to set a bunch of > values that are really part of the config of the parent resource forces > them to use a CLI batch to correctly configure the parent resource. > > > > One thing that I am not sure about this is, how do we do validation for > things like this? > > Simple example would be "required" validation for attribute group. > You want to enforce few attributes that are part of the group to be > required. > > but on other hand you don't want to enforce them as part of resource:add > operation. > as they are only "required" when you are editing / adding attribute group. > > With current code we enforce required for all attributes on a resource > that is being added. > Which is bit inconvenient for when we have attribute groups and want to > do it bit differently. > > So question is should we support selective validation based on groups or > not? > This sounds more like a complex attribute or a child resource. The attributes control a discrete piece of functionality and you need to be able to turn that on/off as a unit. The attributes are required if that functionality is turned on. > > -- > tomaz > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From tomaz.cerar at gmail.com Wed Dec 10 10:05:57 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 10 Dec 2014 16:05:57 +0100 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <54885C79.9070705@redhat.com> References: <548754D5.9090402@redhat.com> <54885C79.9070705@redhat.com> Message-ID: On Wed, Dec 10, 2014 at 3:45 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > This sounds more like a complex attribute or a child resource. The > attributes control a discrete piece of functionality and > you need to be able to turn that on/off as a unit. The attributes are > required if that functionality is turned on. > Agreed, but how do you handle scenario where you just add resource that has 30 attributes all in attribute groups. You call :add() without any parameters as you plan to add/edit attributes that are part of attribute group in next step. you than call :write-attribute(name=non-require-attribute-that-is-part-of-group-that-has-few-required, value="some-value") and this should fail, as attribute is part of attribute group. It is a tricky thing to address, as we have not atomic way to write/update more than one attribute at ones. maybe have extra operation to do write-attribute-group(name="first-attribute-group", attr1=value,attr2=value) similar to :add semantics. otherwise I don't see any good way to do atomic updates of whole attribute group. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141210/3228e55e/attachment.html From devopsmoreorless at gmail.com Wed Dec 10 10:28:56 2014 From: devopsmoreorless at gmail.com (Dev Ops) Date: Wed, 10 Dec 2014 16:28:56 +0100 Subject: [wildfly-dev] Management console web application In-Reply-To: <54885AC3.1070907@redhat.com> References: <54885AC3.1070907@redhat.com> Message-ID: On Wed, Dec 10, 2014 at 3:37 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 12/10/14, 5:14 AM, Dev Ops wrote: > > > > > > On Wed, Dec 10, 2014 at 10:58 AM, Harald Pehl > > wrote: > > > >> > >> Am 09.12.2014 um 12:42 schrieb Dev Ops >> >: > >> > >> Hi, > >> thanks for pointing me to the github repo. > >> > >> I need to do a couple of things: > >> > >> 1. provide a graphical and complete view of all server-groups - > >> along with the hosts - something like the following > >> http://bl.ocks.org/mbostock/1062288 > > That's something we've always wanted to have in the console. > > Currently the console has some weak points when it comes to manage > > big domains with lots of hosts and servers. Some kind of bird's-eye > > view for big topologies would definitely be an improvement. > >> > >> 2. provide a button to download the deployed application; > > Not sure what's the use case behind that. Maybe you can elaborate > > more on that. > > > > > > Most of the time I "operate" in environments and situation where there > > is NOT an artifact repository. > > People merely know the existence of words like CI, CD and so on, thus > > before upgrading a web-application they need to back it up. > > Having a button next to the application can be handy. > > > > Supporting this would require some server-side functionality, as we > don't expose the content in the content repository via the management > API. It would probably be pretty simple to do though, using the > attach-a-stream-to-a-response thing we've added in 9. Used now by the > log download feature. > Great! Thus implementing a download-content button should be pretty straightforward. Dates for WF 9.0.0.Final? More or less... :-) > > > > >> Next would be extending point 2. by providing different colors for > >> different metric values. > >> Likely, heap memory metric going to saturation, the balloon would > >> be colored has almost red (#cc0000)... every hosts could have its > >> own metric (heap memory, cpu usage, connection pool statistics, > >> etc...). > >> Alerts and notifications are not needed, as there are already > >> other software accomplishing these tasks (nagios, jon, etc...). > >> > >> Regards, > >> DevOps guy > > > > Any contributions which address these enhancements are highly > > welcome! The management console is implemented in GWT. There's some > > documentation about the internals and how to get started at [1]. You > > can ping me anytime on #wildfly-management if you need more details > > or to discuss the next steps. > > > > [1] http://hal.github.io/ > > > > .: Harald > > > >> > >> > >> On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl >> > wrote: > >> > >> The source code for the management console lives in its own > >> repository at https://github.com/hal/core > >> > >> I'm curious, what kind of customization do you have in mind? > >> > >> .: Harald > >> > >>> Am 09.12.2014 um 11:06 schrieb Dev Ops > >>> >>: > >>> > >>> Hi all, > >>> where do I find the source of the web application which > >>> provides the Management console? > >>> > >>> I need to add something to it, but I don't know where to get > >>> the source. > >>> > >>> > >>> TIA, > >>> DevOps guy > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org wildfly-dev at lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> --- > >> Harald Pehl > >> JBoss by Red Hat > >> http://hpehl.info > >> > >> > > > > --- > > 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 > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141210/5602292f/attachment-0001.html From brian.stansberry at redhat.com Wed Dec 10 10:51:02 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 09:51:02 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: References: <548754D5.9090402@redhat.com> <54885C79.9070705@redhat.com> Message-ID: <54886BE6.9030405@redhat.com> On 12/10/14, 9:05 AM, Toma? Cerar wrote: > > On Wed, Dec 10, 2014 at 3:45 PM, Brian Stansberry > > wrote: > > This sounds more like a complex attribute or a child resource. The > attributes control a discrete piece of functionality and > you need to be able to turn that on/off as a unit. The attributes > are required if that functionality is turned on. > > > Agreed, but how do you handle scenario where you just add resource that > has 30 attributes all in attribute groups. > You call :add() without any parameters as you plan to add/edit > attributes that are part of attribute group in next step. > you than call > :write-attribute(name=non-require-attribute-that-is-part-of-group-that-has-few-required, > value="some-value") > and this should fail, as attribute is part of attribute group. > You use a batch if it's important to you to format your request into separate lines. Or you just include all the params and use the line separator to break your add up into multiple lines and save a lot of typing. (I'm not really arguing against you ^^^, just pointing out ways to do things in case readers are not aware.) > It is a tricky thing to address, as we have not atomic way to > write/update more than one attribute at ones. > maybe have extra operation to do > write-attribute-group(name="first-attribute-group", > attr1=value,attr2=value) similar to :add semantics. > > otherwise I don't see any good way to do atomic updates of whole > attribute group. > Ok, I'll add this to the "Other possible things to do" bit. Thanks for the input. :) I think "write-attributes(attr1=value,attr2=value)" makes more sense though. This is really syntactic sugar around updating multiple attribute in one op, not requiring client-side creation of a composite. There's no need to tie the concept to the attribute-group notion. > > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Wed Dec 10 10:51:57 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 10 Dec 2014 09:51:57 -0600 Subject: [wildfly-dev] Management console web application In-Reply-To: References: <54885AC3.1070907@redhat.com> Message-ID: > On Dec 10, 2014, at 9:28 AM, Dev Ops wrote: > > > > On Wed, Dec 10, 2014 at 3:37 PM, Brian Stansberry wrote: > On 12/10/14, 5:14 AM, Dev Ops wrote: > > > > > > On Wed, Dec 10, 2014 at 10:58 AM, Harald Pehl > > wrote: > > > >> > >> Am 09.12.2014 um 12:42 schrieb Dev Ops >> >: > >> > >> Hi, > >> thanks for pointing me to the github repo. > >> > >> I need to do a couple of things: > >> > >> 1. provide a graphical and complete view of all server-groups - > >> along with the hosts - something like the following > >> http://bl.ocks.org/mbostock/1062288 > > That's something we've always wanted to have in the console. > > Currently the console has some weak points when it comes to manage > > big domains with lots of hosts and servers. Some kind of bird's-eye > > view for big topologies would definitely be an improvement. > >> > >> 2. provide a button to download the deployed application; > > Not sure what's the use case behind that. Maybe you can elaborate > > more on that. > > > > > > Most of the time I "operate" in environments and situation where there > > is NOT an artifact repository. > > People merely know the existence of words like CI, CD and so on, thus > > before upgrading a web-application they need to back it up. > > Having a button next to the application can be handy. > > > > Supporting this would require some server-side functionality, as we > don't expose the content in the content repository via the management > API. It would probably be pretty simple to do though, using the > attach-a-stream-to-a-response thing we've added in 9. Used now by the > log download feature. > > Great! Thus implementing a download-content button should be pretty straightforward. > > Dates for WF 9.0.0.Final? More or less... :-) > Great question. I am looking to rearrange the scope of 9 so that it can ship in Q1 next year; expect to see an email soon. I?d like to ship the beta end of Jan. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Wed Dec 10 10:52:52 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 09:52:52 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: References: <548754D5.9090402@redhat.com> Message-ID: <54886C54.9070704@redhat.com> On 12/10/14, 9:22 AM, Kabir Khan wrote: > >> On 9 Dec 2014, at 21:00, Brian Stansberry wrote: >> >> Off and on we've had discussions around the idea of "attribute groups". >> We've got some use cases that are crying out for such a thing[1], so I'd >> like to propose doing something concrete but simple for these for WF 9, >> ideally in the next month. >> >> A big part of my goal here is to ensure that whatever we do doesn't >> preclude something more advanced in any next generation management >> stuff, e.g. David's stuff. >> >> PART I Concepts >> >> 1) What is an attribute group? >> >> The "attribute group" concept I propose is simply a collection of >> attributes associated with the same resource type that are independently >> configurable but are statically declared to be conceptually related. The >> group has a name, and members. The name provides a brief indication of >> the nature of the relationship. >> >> The goal is to provide information to the user to help them better >> understand the relationship between attributes. In particular, >> management tools could use this information to visually present related >> attributes together, e.g. in a tab or other grouping widget in the web >> console. >> >> 2) What isn't an attribute group? >> >> Something relevant to writes. >> >> 3) Why would I use a child resource instead of an attribute group? >> >> Because the attributes control a discrete piece of functionality and you >> need to be able to turn that on or off as a unit. So you add/remove the >> resource. >> >> 4) Why would I use a complex attribute with a bunch of fields instead of >> n>1 simple attributes in a group. >> >> a) Because the attributes control a discrete piece of functionality and >> you need to be able to turn that off as a unit. So users can undefine >> the complex attribute. >> >> b) Because it's a common use case that modifications to n>1 of the >> fields should be done atomically and you don't want to force users to >> use a CLI batch. So you let them use write-attribute and specify the >> value of all the fields. > Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? > Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions > On the branch of the thread where I'm discussing with Tomaz, he raised the same idea, which I think is a good one. I think a "write-attributes" with no relationship to attribute-group makes more sense though. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 10:54:07 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 09:54:07 -0600 Subject: [wildfly-dev] Management console web application In-Reply-To: References: <54885AC3.1070907@redhat.com> Message-ID: <54886C9F.2000007@redhat.com> On 12/10/14, 9:28 AM, Dev Ops wrote: > > > On Wed, Dec 10, 2014 at 3:37 PM, Brian Stansberry > > wrote: > > On 12/10/14, 5:14 AM, Dev Ops wrote: > > > > > > On Wed, Dec 10, 2014 at 10:58 AM, Harald Pehl > > >> wrote: > > > >> > >> Am 09.12.2014 um 12:42 schrieb Dev Ops > >> >>: > >> > >> Hi, > >> thanks for pointing me to the github repo. > >> > >> I need to do a couple of things: > >> > >> 1. provide a graphical and complete view of all server-groups - > >> along with the hosts - something like the following > >>http://bl.ocks.org/mbostock/1062288 > > That's something we've always wanted to have in the console. > > Currently the console has some weak points when it comes to manage > > big domains with lots of hosts and servers. Some kind of bird's-eye > > view for big topologies would definitely be an improvement. > >> > >> 2. provide a button to download the deployed application; > > Not sure what's the use case behind that. Maybe you can elaborate > > more on that. > > > > > > Most of the time I "operate" in environments and situation where there > > is NOT an artifact repository. > > People merely know the existence of words like CI, CD and so on, thus > > before upgrading a web-application they need to back it up. > > Having a button next to the application can be handy. > > > > Supporting this would require some server-side functionality, as we > don't expose the content in the content repository via the management > API. It would probably be pretty simple to do though, using the > attach-a-stream-to-a-response thing we've added in 9. Used now by the > log download feature. > > > Great! Thus implementing a download-content button should be pretty > straightforward. > Are you saying you plan to take on the server-side bit? That would be great, and I'd be happy to help out. > Dates for WF 9.0.0.Final? More or less... :-) > > > > > >> Next would be extending point 2. by providing different colors for > >> different metric values. > >> Likely, heap memory metric going to saturation, the balloon would > >> be colored has almost red (#cc0000)... every hosts could have its > >> own metric (heap memory, cpu usage, connection pool statistics, > >> etc...). > >> Alerts and notifications are not needed, as there are already > >> other software accomplishing these tasks (nagios, jon, etc...). > >> > >> Regards, > >> DevOps guy > > > > Any contributions which address these enhancements are highly > > welcome! The management console is implemented in GWT. There's some > > documentation about the internals and how to get started at [1]. You > > can ping me anytime on #wildfly-management if you need more details > > or to discuss the next steps. > > > > [1]http://hal.github.io/ > > > > .: Harald > > > >> > >> > >> On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl > >> >> wrote: > >> > >> The source code for the management console lives in its own > >> repository athttps://github.com/hal/core > >> > >> I'm curious, what kind of customization do you have in mind? > >> > >> .: Harald > >> > >>> Am 09.12.2014 um 11:06 schrieb Dev Ops > >>> > >>: > >>> > >>> Hi all, > >>> where do I find the source of the web application which > >>> provides the Management console? > >>> > >>> I need to add something to it, but I don't know where to get > >>> the source. > >>> > >>> > >>> TIA, > >>> DevOps guy > >>> _______________________________________________ > >>> 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 > >> > >> > > > > --- > > 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 > 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 Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Wed Dec 10 11:02:28 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 10 Dec 2014 10:02:28 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <548856ED.9010809@redhat.com> References: <548754D5.9090402@redhat.com> <5488199B.8010608@redhat.com> <548856ED.9010809@redhat.com> Message-ID: <54886E94.7020507@redhat.com> On 12/10/2014 08:21 AM, Brian Stansberry wrote: > On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote: >> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ? > > This is what I meant by > > "4) Low level management API > > The output of read-resource and read-resource-description is modified > such that attributes are sorted by group name and then by attribute name." > > I used the verb "sorted" though because I have no intent of modifying > the output structure by creating a level for the attribute group. That > would be an incompatible change in the output format and would obscure > the distinction between an attribute group and a complex attribute. FWIW I think this is a good distinction and a good approach. >> Is aliasing to be supported ? What if I want to change the attribute group name ? >> > > Good question. > > Heiko, I don't think Emmanuel is talking about users changing this. We > use aliasing in other contexts as a mechanism for maintaining > compatibility. If something is poorly named (e.g. a bad resource address > name) we can fix it in a later release but also register an alias under > the old name to provide compatibility. > > I don't see how aliasing could work here. Only thing I can imagine is > using it in the ls -l output, such that the same attribute can appear > > 1 times, if it is associated with more than 1 group. I suppose a console > could do a similar thing, but I don't at all regard maintaining that > kind of compatibility in UI layout to be a requirement. > > I'm not sure how much we regard consistency in the ls -l output across > releases as being a requirement. I think of that as being an output > format for humans, not machines. > > Aliasing is an example of a reason for allowing an attribute to belong > to more than one group. There may be others. Perhaps as an aid to querying? I still feel strongly that we should look to real resource versioning as the proper solution here, though I realize there has not been a satisfactory resolution to this discussion. But the longer we don't come to a resolution, the more (arguably questionable) tricks we have to pull to manage compatibility. -- - DML From devopsmoreorless at gmail.com Wed Dec 10 11:03:18 2014 From: devopsmoreorless at gmail.com (Dev Ops) Date: Wed, 10 Dec 2014 17:03:18 +0100 Subject: [wildfly-dev] Management console web application In-Reply-To: <54886C9F.2000007@redhat.com> References: <54885AC3.1070907@redhat.com> <54886C9F.2000007@redhat.com> Message-ID: On Wed, Dec 10, 2014 at 4:54 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 12/10/14, 9:28 AM, Dev Ops wrote: > >> >> >> On Wed, Dec 10, 2014 at 3:37 PM, Brian Stansberry >> > wrote: >> >> On 12/10/14, 5:14 AM, Dev Ops wrote: >> > >> > >> > On Wed, Dec 10, 2014 at 10:58 AM, Harald Pehl > >> > >> wrote: >> > >> >> >> >> Am 09.12.2014 um 12:42 schrieb Dev Ops < >> devopsmoreorless at gmail.com >> >> > >> >>: >> >> >> >> Hi, >> >> thanks for pointing me to the github repo. >> >> >> >> I need to do a couple of things: >> >> >> >> 1. provide a graphical and complete view of all >> server-groups - >> >> along with the hosts - something like the following >> >>http://bl.ocks.org/mbostock/1062288 >> > That's something we've always wanted to have in the console. >> > Currently the console has some weak points when it comes to >> manage >> > big domains with lots of hosts and servers. Some kind of >> bird's-eye >> > view for big topologies would definitely be an improvement. >> >> >> >> 2. provide a button to download the deployed application; >> > Not sure what's the use case behind that. Maybe you can >> elaborate >> > more on that. >> > >> > >> > Most of the time I "operate" in environments and situation where >> there >> > is NOT an artifact repository. >> > People merely know the existence of words like CI, CD and so on, >> thus >> > before upgrading a web-application they need to back it up. >> > Having a button next to the application can be handy. >> > >> >> Supporting this would require some server-side functionality, as we >> don't expose the content in the content repository via the management >> API. It would probably be pretty simple to do though, using the >> attach-a-stream-to-a-response thing we've added in 9. Used now by the >> log download feature. >> >> >> Great! Thus implementing a download-content button should be pretty >> straightforward. >> >> > Are you saying you plan to take on the server-side bit? That would be > great, and I'd be happy to help out. > Let's say, I'll try to take a look at it this week-end cloning the https://github.com/hal/core repo. By the way... which branch/tag should I "work" on? > Dates for WF 9.0.0.Final? More or less... :-) >> >> >> > >> >> Next would be extending point 2. by providing different colors >> for >> >> different metric values. >> >> Likely, heap memory metric going to saturation, the balloon >> would >> >> be colored has almost red (#cc0000)... every hosts could have >> its >> >> own metric (heap memory, cpu usage, connection pool statistics, >> >> etc...). >> >> Alerts and notifications are not needed, as there are already >> >> other software accomplishing these tasks (nagios, jon, etc...). >> >> >> >> Regards, >> >> DevOps guy >> > >> > Any contributions which address these enhancements are highly >> > welcome! The management console is implemented in GWT. There's >> some >> > documentation about the internals and how to get started at >> [1]. You >> > can ping me anytime on #wildfly-management if you need more >> details >> > or to discuss the next steps. >> > >> > [1]http://hal.github.io/ >> > >> > .: Harald >> > >> >> >> >> >> >> On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl > >> >> >> wrote: >> >> >> >> The source code for the management console lives in its own >> >> repository athttps://github.com/hal/core >> >> >> >> I'm curious, what kind of customization do you have in >> mind? >> >> >> >> .: Harald >> >> >> >>> Am 09.12.2014 um 11:06 schrieb Dev Ops >> >>> > >> > >>: >> >>> >> >>> Hi all, >> >>> where do I find the source of the web application which >> >>> provides the Management console? >> >>> >> >>> I need to add something to it, but I don't know where to >> get >> >>> the source. >> >>> >> >>> >> >>> TIA, >> >>> DevOps guy >> >>> _______________________________________________ >> >>> 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 >> >> >> >> >> > >> > --- >> > 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 >> 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 > Senior Principal Software Engineer > JBoss by Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141210/f6dcc4ed/attachment-0001.html From kabir.khan at jboss.com Wed Dec 10 10:22:27 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 10 Dec 2014 16:22:27 +0100 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <548754D5.9090402@redhat.com> References: <548754D5.9090402@redhat.com> Message-ID: > On 9 Dec 2014, at 21:00, Brian Stansberry wrote: > > Off and on we've had discussions around the idea of "attribute groups". > We've got some use cases that are crying out for such a thing[1], so I'd > like to propose doing something concrete but simple for these for WF 9, > ideally in the next month. > > A big part of my goal here is to ensure that whatever we do doesn't > preclude something more advanced in any next generation management > stuff, e.g. David's stuff. > > PART I Concepts > > 1) What is an attribute group? > > The "attribute group" concept I propose is simply a collection of > attributes associated with the same resource type that are independently > configurable but are statically declared to be conceptually related. The > group has a name, and members. The name provides a brief indication of > the nature of the relationship. > > The goal is to provide information to the user to help them better > understand the relationship between attributes. In particular, > management tools could use this information to visually present related > attributes together, e.g. in a tab or other grouping widget in the web > console. > > 2) What isn't an attribute group? > > Something relevant to writes. > > 3) Why would I use a child resource instead of an attribute group? > > Because the attributes control a discrete piece of functionality and you > need to be able to turn that on or off as a unit. So you add/remove the > resource. > > 4) Why would I use a complex attribute with a bunch of fields instead of > n>1 simple attributes in a group. > > a) Because the attributes control a discrete piece of functionality and > you need to be able to turn that off as a unit. So users can undefine > the complex attribute. > > b) Because it's a common use case that modifications to n>1 of the > fields should be done atomically and you don't want to force users to > use a CLI batch. So you let them use write-attribute and specify the > value of all the fields. Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions > > 5) Why would I use an attribute group instead of a child resource? > > Because requiring users to add a child resource just to set a bunch of > values that are really part of the config of the parent resource forces > them to use a CLI batch to correctly configure the parent resource. > > 6) Why would I use an attribute group instead a complex attribute? > > Because the various attributes should be independently configurable. In > particular, wiping out the config for all of them by simply undefining > the complex attribute isn't appropriate. > > PART II Proposed Work > > 1) The basics > > We add a piece of metadata to the read-resource-description output for > an attribute. Name is 'attribute-group', value type is ModelType.STRING, > value is the name of the group, with 'undefined' allowed. > > The group is simply the set of attributes that share the same string. > > To implement this, we add public String > AttributeDefinition.getAttributeGroup() and add support for setting it > to the relevant Builder. ReadResourceDescriptionHandler outputs the value. > > 2) XML parsing/marshalling > > Modify PersistentResourceXMLDescription such that attributes in an > attribute group get persisted in their own child element, whose name is > the name of the group. > > PersistentResourceXMLBuilder exposes a setter to allow users to turn > this on/off for that resource. Turning it off will allow the addition of > attribute group settings for a resource without requiring an immediate > corresponding xsd change. > > 3) Web console > > HAL can make use of the additional metadata at its leisure, and as it > becomes available. > > 4) Low level management API > > The output of read-resource and read-resource-description is modified > such that attributes are sorted by group name and then by attribute name. > > 5) CLI > > I'm not clear on exactly what to do here, but my instinct is the output > of the 'ls -l' command should be modified. Probably add a GROUP column > to the right and sort the order of attributes by group and then by > attribute name. > > PART III Other possible things to do > > A :read-attribute-group(name=) operation or an > "attribute-groups=[*]" param to :read-resource, to make it > convenient to read a set of attributes without needing to read the > entire resource. > > We could also consider adding an "attribute-groups" section to the > read-resource-description output, where a fuller i18n text description > of the meaning of the group could be written. If we do this we should > probably do it in WF 9 as it will likely add some sort of requirement to > subsystem authors that we expose right from the start. > > > If you're still awake, comments as always are appreciated. > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > > [1] For example, the JDKORB pull request at > https://github.com/wildfly/wildfly/pull/7008 uses child resources in a > number of places where it seems like attribute groups are a better fit. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From devopsmoreorless at gmail.com Wed Dec 10 11:18:53 2014 From: devopsmoreorless at gmail.com (Dev Ops) Date: Wed, 10 Dec 2014 17:18:53 +0100 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <54886C54.9070704@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> Message-ID: On Wed, Dec 10, 2014 at 4:52 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 12/10/14, 9:22 AM, Kabir Khan wrote: > > > >> On 9 Dec 2014, at 21:00, Brian Stansberry > wrote: > >> > >> Off and on we've had discussions around the idea of "attribute groups". > >> We've got some use cases that are crying out for such a thing[1], so I'd > >> like to propose doing something concrete but simple for these for WF 9, > >> ideally in the next month. > >> > >> A big part of my goal here is to ensure that whatever we do doesn't > >> preclude something more advanced in any next generation management > >> stuff, e.g. David's stuff. > >> > >> PART I Concepts > >> > >> 1) What is an attribute group? > >> > >> The "attribute group" concept I propose is simply a collection of > >> attributes associated with the same resource type that are independently > >> configurable but are statically declared to be conceptually related. The > >> group has a name, and members. The name provides a brief indication of > >> the nature of the relationship. > >> > >> The goal is to provide information to the user to help them better > >> understand the relationship between attributes. In particular, > >> management tools could use this information to visually present related > >> attributes together, e.g. in a tab or other grouping widget in the web > >> console. > >> > >> 2) What isn't an attribute group? > >> > >> Something relevant to writes. > >> > >> 3) Why would I use a child resource instead of an attribute group? > >> > >> Because the attributes control a discrete piece of functionality and you > >> need to be able to turn that on or off as a unit. So you add/remove the > >> resource. > >> > >> 4) Why would I use a complex attribute with a bunch of fields instead of > >> n>1 simple attributes in a group. > >> > >> a) Because the attributes control a discrete piece of functionality and > >> you need to be able to turn that off as a unit. So users can undefine > >> the complex attribute. > >> > >> b) Because it's a common use case that modifications to n>1 of the > >> fields should be done atomically and you don't want to force users to > >> use a CLI batch. So you let them use write-attribute and specify the > >> value of all the fields. > > Why not something along the lines of > :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? > > Internally that could create a composite for us, giving complex > attribute functionality while avoiding the messy resource descriptions > > > > On the branch of the thread where I'm discussing with Tomaz, he raised > the same idea, which I think is a good one. I think a "write-attributes" > with no relationship to attribute-group makes more sense though. > In your preamble you said: [...] The "attribute group" concept I propose is simply a collection of attributes associated with the same resource type that are independently configurable but are statically declared to be conceptually related. The group has a name, and members. The name provides a brief indication of the nature of the relationship. [...] Doesn't it clash with your last thought? > > -- > Brian Stansberry > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141210/e33faf89/attachment.html From david.lloyd at redhat.com Wed Dec 10 11:06:30 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 10 Dec 2014 10:06:30 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <54886C54.9070704@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> Message-ID: <54886F86.2020706@redhat.com> On 12/10/2014 09:52 AM, Brian Stansberry wrote: > On 12/10/14, 9:22 AM, Kabir Khan wrote: >> >>> On 9 Dec 2014, at 21:00, Brian Stansberry wrote: >>> >>> Off and on we've had discussions around the idea of "attribute groups". >>> We've got some use cases that are crying out for such a thing[1], so I'd >>> like to propose doing something concrete but simple for these for WF 9, >>> ideally in the next month. >>> >>> A big part of my goal here is to ensure that whatever we do doesn't >>> preclude something more advanced in any next generation management >>> stuff, e.g. David's stuff. >>> >>> PART I Concepts >>> >>> 1) What is an attribute group? >>> >>> The "attribute group" concept I propose is simply a collection of >>> attributes associated with the same resource type that are independently >>> configurable but are statically declared to be conceptually related. The >>> group has a name, and members. The name provides a brief indication of >>> the nature of the relationship. >>> >>> The goal is to provide information to the user to help them better >>> understand the relationship between attributes. In particular, >>> management tools could use this information to visually present related >>> attributes together, e.g. in a tab or other grouping widget in the web >>> console. >>> >>> 2) What isn't an attribute group? >>> >>> Something relevant to writes. >>> >>> 3) Why would I use a child resource instead of an attribute group? >>> >>> Because the attributes control a discrete piece of functionality and you >>> need to be able to turn that on or off as a unit. So you add/remove the >>> resource. >>> >>> 4) Why would I use a complex attribute with a bunch of fields instead of >>> n>1 simple attributes in a group. >>> >>> a) Because the attributes control a discrete piece of functionality and >>> you need to be able to turn that off as a unit. So users can undefine >>> the complex attribute. >>> >>> b) Because it's a common use case that modifications to n>1 of the >>> fields should be done atomically and you don't want to force users to >>> use a CLI batch. So you let them use write-attribute and specify the >>> value of all the fields. >> Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >> Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions >> > > On the branch of the thread where I'm discussing with Tomaz, he raised > the same idea, which I think is a good one. I think a "write-attributes" > with no relationship to attribute-group makes more sense though. I agree. I have always felt that we should allow more than level of grouping. Having a special operation that "knows about" attribute groups in some special way is thus precluded; simply having a multiple "write-attributes" fits in nicely with the concept that a resource is actually our basic atomic unit of granularity. -- - DML From brian.stansberry at redhat.com Wed Dec 10 11:27:29 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 10:27:29 -0600 Subject: [wildfly-dev] Management console web application In-Reply-To: References: <54885AC3.1070907@redhat.com> <54886C9F.2000007@redhat.com> Message-ID: <54887471.9080005@redhat.com> On 12/10/14, 10:03 AM, Dev Ops wrote: > > > On Wed, Dec 10, 2014 at 4:54 PM, Brian Stansberry > > wrote: > > On 12/10/14, 9:28 AM, Dev Ops wrote: > > > > On Wed, Dec 10, 2014 at 3:37 PM, Brian Stansberry > > >> wrote: > > On 12/10/14, 5:14 AM, Dev Ops wrote: > > > > > > On Wed, Dec 10, 2014 at 10:58 AM, Harald Pehl > > > > > > >>> wrote: > > > >> > >> Am 09.12.2014 um 12:42 schrieb Dev Ops > > > > >> > > >>>: > >> > >> Hi, > >> thanks for pointing me to the github repo. > >> > >> I need to do a couple of things: > >> > >> 1. provide a graphical and complete view of all > server-groups - > >> along with the hosts - something like the following > >>http://bl.ocks.org/mbostock/__1062288 > > > That's something we've always wanted to have in the > console. > > Currently the console has some weak points when it > comes to manage > > big domains with lots of hosts and servers. Some kind > of bird's-eye > > view for big topologies would definitely be an > improvement. > >> > >> 2. provide a button to download the deployed > application; > > Not sure what's the use case behind that. Maybe you > can elaborate > > more on that. > > > > > > Most of the time I "operate" in environments and > situation where there > > is NOT an artifact repository. > > People merely know the existence of words like CI, CD and > so on, thus > > before upgrading a web-application they need to back it up. > > Having a button next to the application can be handy. > > > > Supporting this would require some server-side > functionality, as we > don't expose the content in the content repository via the > management > API. It would probably be pretty simple to do though, using the > attach-a-stream-to-a-response thing we've added in 9. Used > now by the > log download feature. > > > Great! Thus implementing a download-content button should be pretty > straightforward. > > > Are you saying you plan to take on the server-side bit? That would > be great, and I'd be happy to help out. > > > Let's say, I'll try to take a look at it this week-end cloning the > https://github.com/hal/core repo. The server side is not in HAL, it would be a change to https://github.com/wildfly/wildfly-core, branch "master". I've opened a JIRA for the server-side piece: https://issues.jboss.org/browse/WFCORE-456 > By the way... which branch/tag should I "work" on? > I'll let Harald/Heiko answer that. > > Dates for WF 9.0.0.Final? More or less... :-) > > > > > >> Next would be extending point 2. by providing > different colors for > >> different metric values. > >> Likely, heap memory metric going to saturation, the > balloon would > >> be colored has almost red (#cc0000)... every hosts > could have its > >> own metric (heap memory, cpu usage, connection pool > statistics, > >> etc...). > >> Alerts and notifications are not needed, as there > are already > >> other software accomplishing these tasks (nagios, > jon, etc...). > >> > >> Regards, > >> DevOps guy > > > > Any contributions which address these enhancements > are highly > > welcome! The management console is implemented in > GWT. There's some > > documentation about the internals and how to get > started at [1]. You > > can ping me anytime on #wildfly-management if you > need more details > > or to discuss the next steps. > > > > [1]http://hal.github.io/ > > > > .: Harald > > > >> > >> > >> On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl > > > > >> > >>> wrote: > >> > >> The source code for the management console lives > in its own > >> repository athttps://github.com/hal/core > > >> > >> I'm curious, what kind of customization do you > have in mind? > >> > >> .: Harald > >> > >>> Am 09.12.2014 um 11:06 schrieb Dev Ops > >>> > > > > >>>: > >>> > >>> Hi all, > >>> where do I find the source of the web > application which > >>> provides the Management console? > >>> > >>> I need to add something to it, but I don't know > where to get > >>> the source. > >>> > >>> > >>> TIA, > >>> DevOps guy > >>> _________________________________________________ > >>> 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 > >> > >> > > > > --- > > 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 > 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 > Senior Principal Software Engineer > JBoss by Red Hat > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 11:30:37 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 10:30:37 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <54886F86.2020706@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> Message-ID: <5488752D.3050706@redhat.com> On 12/10/14, 10:06 AM, David M. Lloyd wrote: > On 12/10/2014 09:52 AM, Brian Stansberry wrote: >> On 12/10/14, 9:22 AM, Kabir Khan wrote: >>> >>>> On 9 Dec 2014, at 21:00, Brian Stansberry wrote: >>>> >>>> Off and on we've had discussions around the idea of "attribute groups". >>>> We've got some use cases that are crying out for such a thing[1], so I'd >>>> like to propose doing something concrete but simple for these for WF 9, >>>> ideally in the next month. >>>> >>>> A big part of my goal here is to ensure that whatever we do doesn't >>>> preclude something more advanced in any next generation management >>>> stuff, e.g. David's stuff. >>>> >>>> PART I Concepts >>>> >>>> 1) What is an attribute group? >>>> >>>> The "attribute group" concept I propose is simply a collection of >>>> attributes associated with the same resource type that are independently >>>> configurable but are statically declared to be conceptually related. The >>>> group has a name, and members. The name provides a brief indication of >>>> the nature of the relationship. >>>> >>>> The goal is to provide information to the user to help them better >>>> understand the relationship between attributes. In particular, >>>> management tools could use this information to visually present related >>>> attributes together, e.g. in a tab or other grouping widget in the web >>>> console. >>>> >>>> 2) What isn't an attribute group? >>>> >>>> Something relevant to writes. >>>> >>>> 3) Why would I use a child resource instead of an attribute group? >>>> >>>> Because the attributes control a discrete piece of functionality and you >>>> need to be able to turn that on or off as a unit. So you add/remove the >>>> resource. >>>> >>>> 4) Why would I use a complex attribute with a bunch of fields instead of >>>> n>1 simple attributes in a group. >>>> >>>> a) Because the attributes control a discrete piece of functionality and >>>> you need to be able to turn that off as a unit. So users can undefine >>>> the complex attribute. >>>> >>>> b) Because it's a common use case that modifications to n>1 of the >>>> fields should be done atomically and you don't want to force users to >>>> use a CLI batch. So you let them use write-attribute and specify the >>>> value of all the fields. >>> Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >>> Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions >>> >> >> On the branch of the thread where I'm discussing with Tomaz, he raised >> the same idea, which I think is a good one. I think a "write-attributes" >> with no relationship to attribute-group makes more sense though. > > I agree. I have always felt that we should allow more than level of > grouping. Did you mean "should NOT allow"? > Having a special operation that "knows about" attribute > groups in some special way is thus precluded; simply having a multiple > "write-attributes" fits in nicely with the concept that a resource is > actually our basic atomic unit of granularity. > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 11:39:03 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 10:39:03 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> Message-ID: <54887727.8020708@redhat.com> On 12/10/14, 10:18 AM, Dev Ops wrote: > > > On Wed, Dec 10, 2014 at 4:52 PM, Brian Stansberry > > wrote: > > On 12/10/14, 9:22 AM, Kabir Khan wrote: > > > >> On 9 Dec 2014, at 21:00, Brian Stansberry > > > wrote: > >> > >> Off and on we've had discussions around the idea of "attribute > groups". > >> We've got some use cases that are crying out for such a > thing[1], so I'd > >> like to propose doing something concrete but simple for these > for WF 9, > >> ideally in the next month. > >> > >> A big part of my goal here is to ensure that whatever we do doesn't > >> preclude something more advanced in any next generation management > >> stuff, e.g. David's stuff. > >> > >> PART I Concepts > >> > >> 1) What is an attribute group? > >> > >> The "attribute group" concept I propose is simply a collection of > >> attributes associated with the same resource type that are > independently > >> configurable but are statically declared to be conceptually > related. The > >> group has a name, and members. The name provides a brief > indication of > >> the nature of the relationship. > >> > >> The goal is to provide information to the user to help them better > >> understand the relationship between attributes. In particular, > >> management tools could use this information to visually present > related > >> attributes together, e.g. in a tab or other grouping widget in > the web > >> console. > >> > >> 2) What isn't an attribute group? > >> > >> Something relevant to writes. > >> > >> 3) Why would I use a child resource instead of an attribute group? > >> > >> Because the attributes control a discrete piece of functionality > and you > >> need to be able to turn that on or off as a unit. So you > add/remove the > >> resource. > >> > >> 4) Why would I use a complex attribute with a bunch of fields > instead of > >> n>1 simple attributes in a group. > >> > >> a) Because the attributes control a discrete piece of > functionality and > >> you need to be able to turn that off as a unit. So users can > undefine > >> the complex attribute. > >> > >> b) Because it's a common use case that modifications to n>1 of the > >> fields should be done atomically and you don't want to force > users to > >> use a CLI batch. So you let them use write-attribute and specify the > >> value of all the fields. > > Why not something along the lines of > :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? > > Internally that could create a composite for us, giving complex > attribute functionality while avoiding the messy resource descriptions > > > > On the branch of the thread where I'm discussing with Tomaz, he raised > the same idea, which I think is a good one. I think a "write-attributes" > with no relationship to attribute-group makes more sense though. > > > In your preamble you said: > > [...] The "attribute group" concept I propose is simply a collection of > attributes associated with the same resource type that are independently > configurable but are statically declared to be conceptually related. The > group has a name, and members. The name provides a brief indication of > the nature of the relationship. [...] > > Doesn't it clash with your last thought? > I don't think so. Attributes can be independently configurable, but it's still valid for a user to want to change several of them in a single atomic operation. Users can do that via a CLI batch, which internally uses the low-level "composite" operation (which is used by the console as well). This "write-attributes" op is just a different syntax to atomically update several things. It's much less verbose than doing the same thing with batch/composite but is limited to a single use case of changing several attributes on the same resource. Of course if you want to change several attributes each on several different resources you could use batch/composite in combination with write-attributes and save quite a bit of typing. > > -- > Brian Stansberry > 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 Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 12:01:18 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 11:01:18 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <54886E94.7020507@redhat.com> References: <548754D5.9090402@redhat.com> <5488199B.8010608@redhat.com> <548856ED.9010809@redhat.com> <54886E94.7020507@redhat.com> Message-ID: <54887C5E.6070405@redhat.com> On 12/10/14, 10:02 AM, David M. Lloyd wrote: > On 12/10/2014 08:21 AM, Brian Stansberry wrote: >> On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote: >>> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ? >> >> This is what I meant by >> >> "4) Low level management API >> >> The output of read-resource and read-resource-description is modified >> such that attributes are sorted by group name and then by attribute name." >> >> I used the verb "sorted" though because I have no intent of modifying >> the output structure by creating a level for the attribute group. That >> would be an incompatible change in the output format and would obscure >> the distinction between an attribute group and a complex attribute. > > FWIW I think this is a good distinction and a good approach. > >>> Is aliasing to be supported ? What if I want to change the attribute group name ? >>> >> >> Good question. >> >> Heiko, I don't think Emmanuel is talking about users changing this. We >> use aliasing in other contexts as a mechanism for maintaining >> compatibility. If something is poorly named (e.g. a bad resource address >> name) we can fix it in a later release but also register an alias under >> the old name to provide compatibility. >> >> I don't see how aliasing could work here. Only thing I can imagine is >> using it in the ls -l output, such that the same attribute can appear > >> 1 times, if it is associated with more than 1 group. I suppose a console >> could do a similar thing, but I don't at all regard maintaining that >> kind of compatibility in UI layout to be a requirement. >> >> I'm not sure how much we regard consistency in the ls -l output across >> releases as being a requirement. I think of that as being an output >> format for humans, not machines. >> >> Aliasing is an example of a reason for allowing an attribute to belong >> to more than one group. There may be others. Perhaps as an aid to querying? > > I still feel strongly that we should look to real resource versioning as > the proper solution here, though I realize there has not been a > satisfactory resolution to this discussion. But the longer we don't > come to a resolution, the more (arguably questionable) tricks we have to > pull to manage compatibility. > Agreed, at least re: we need to come to a resolution and that I don't want to add further tricks. So I don't see the aliasing use case as being a sufficient justification for allowing an attribute to be associated with > 1 group. The (vague) querying notion is more interesting to me as a reason for allowing > 1 group. Really all I've described here is a form of tagging attributes. However, separating "tags" for querying from "attribute-group" which is specifically intended as a primary grouping clue for management UIs is IMO better. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 12:03:13 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 11:03:13 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <54887C5E.6070405@redhat.com> References: <548754D5.9090402@redhat.com> <5488199B.8010608@redhat.com> <548856ED.9010809@redhat.com> <54886E94.7020507@redhat.com> <54887C5E.6070405@redhat.com> Message-ID: <54887CD1.9030902@redhat.com> On 12/10/14, 11:01 AM, Brian Stansberry wrote: > On 12/10/14, 10:02 AM, David M. Lloyd wrote: >> On 12/10/2014 08:21 AM, Brian Stansberry wrote: >>> On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote: >>>> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ? >>> >>> This is what I meant by >>> >>> "4) Low level management API >>> >>> The output of read-resource and read-resource-description is modified >>> such that attributes are sorted by group name and then by attribute name." >>> >>> I used the verb "sorted" though because I have no intent of modifying >>> the output structure by creating a level for the attribute group. That >>> would be an incompatible change in the output format and would obscure >>> the distinction between an attribute group and a complex attribute. >> >> FWIW I think this is a good distinction and a good approach. >> >>>> Is aliasing to be supported ? What if I want to change the attribute group name ? >>>> >>> >>> Good question. >>> >>> Heiko, I don't think Emmanuel is talking about users changing this. We >>> use aliasing in other contexts as a mechanism for maintaining >>> compatibility. If something is poorly named (e.g. a bad resource address >>> name) we can fix it in a later release but also register an alias under >>> the old name to provide compatibility. >>> >>> I don't see how aliasing could work here. Only thing I can imagine is >>> using it in the ls -l output, such that the same attribute can appear > >>> 1 times, if it is associated with more than 1 group. I suppose a console >>> could do a similar thing, but I don't at all regard maintaining that >>> kind of compatibility in UI layout to be a requirement. >>> >>> I'm not sure how much we regard consistency in the ls -l output across >>> releases as being a requirement. I think of that as being an output >>> format for humans, not machines. >>> >>> Aliasing is an example of a reason for allowing an attribute to belong >>> to more than one group. There may be others. Perhaps as an aid to querying? >> >> I still feel strongly that we should look to real resource versioning as >> the proper solution here, though I realize there has not been a >> satisfactory resolution to this discussion. But the longer we don't >> come to a resolution, the more (arguably questionable) tricks we have to >> pull to manage compatibility. >> > > Agreed, at least re: we need to come to a resolution and that I don't > want to add further tricks. So I don't see the aliasing use case as > being a sufficient justification for allowing an attribute to be > associated with > 1 group. > Hit send too early -- meant to say I'll try and think a lot about the versioning thing over the holidays when I'll be away from email/chat/etc and can actually focus on something big. > The (vague) querying notion is more interesting to me as a reason for > allowing > 1 group. Really all I've described here is a form of tagging > attributes. However, separating "tags" for querying from > "attribute-group" which is specifically intended as a primary grouping > clue for management UIs is IMO better. > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Wed Dec 10 12:44:43 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 10 Dec 2014 11:44:43 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488752D.3050706@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> Message-ID: <5488868B.9070306@redhat.com> Forgot to hit "reply to list" on this one. On 12/10/2014 10:30 AM, Brian Stansberry wrote: > On 12/10/14, 10:06 AM, David M. Lloyd wrote: >> On 12/10/2014 09:52 AM, Brian Stansberry wrote: >>> On 12/10/14, 9:22 AM, Kabir Khan wrote: >>>> >>>>> On 9 Dec 2014, at 21:00, Brian Stansberry wrote: >>>>> >>>>> Off and on we've had discussions around the idea of "attribute groups". >>>>> We've got some use cases that are crying out for such a thing[1], so I'd >>>>> like to propose doing something concrete but simple for these for WF 9, >>>>> ideally in the next month. >>>>> >>>>> A big part of my goal here is to ensure that whatever we do doesn't >>>>> preclude something more advanced in any next generation management >>>>> stuff, e.g. David's stuff. >>>>> >>>>> PART I Concepts >>>>> >>>>> 1) What is an attribute group? >>>>> >>>>> The "attribute group" concept I propose is simply a collection of >>>>> attributes associated with the same resource type that are independently >>>>> configurable but are statically declared to be conceptually related. The >>>>> group has a name, and members. The name provides a brief indication of >>>>> the nature of the relationship. >>>>> >>>>> The goal is to provide information to the user to help them better >>>>> understand the relationship between attributes. In particular, >>>>> management tools could use this information to visually present related >>>>> attributes together, e.g. in a tab or other grouping widget in the web >>>>> console. >>>>> >>>>> 2) What isn't an attribute group? >>>>> >>>>> Something relevant to writes. >>>>> >>>>> 3) Why would I use a child resource instead of an attribute group? >>>>> >>>>> Because the attributes control a discrete piece of functionality and you >>>>> need to be able to turn that on or off as a unit. So you add/remove the >>>>> resource. >>>>> >>>>> 4) Why would I use a complex attribute with a bunch of fields instead of >>>>> n>1 simple attributes in a group. >>>>> >>>>> a) Because the attributes control a discrete piece of functionality and >>>>> you need to be able to turn that off as a unit. So users can undefine >>>>> the complex attribute. >>>>> >>>>> b) Because it's a common use case that modifications to n>1 of the >>>>> fields should be done atomically and you don't want to force users to >>>>> use a CLI batch. So you let them use write-attribute and specify the >>>>> value of all the fields. >>>> Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >>>> Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions >>>> >>> >>> On the branch of the thread where I'm discussing with Tomaz, he raised >>> the same idea, which I think is a good one. I think a "write-attributes" >>> with no relationship to attribute-group makes more sense though. >> >> I agree. I have always felt that we should allow more than level of >> grouping. > > Did you mean "should NOT allow"? No, I mean multiple levels _should_ be allowed, just with multiple qualifiers. Multiple attribute writing per resource _should_ be allowed regardless of the depth or mixture of nesting. I.e. I should be able to do something like :write-attributes({"foo" = 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard necessary to deal with attribute group navigation. -- - DML From brian.stansberry at redhat.com Wed Dec 10 12:52:31 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 11:52:31 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488868B.9070306@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> Message-ID: <5488885F.5030103@redhat.com> On 12/10/14, 11:44 AM, David M. Lloyd wrote: > Forgot to hit "reply to list" on this one. > > On 12/10/2014 10:30 AM, Brian Stansberry wrote: >> On 12/10/14, 10:06 AM, David M. Lloyd wrote: >>> On 12/10/2014 09:52 AM, Brian Stansberry wrote: >>>> On 12/10/14, 9:22 AM, Kabir Khan wrote: >>>>> >>>>>> On 9 Dec 2014, at 21:00, Brian Stansberry wrote: >>>>>> >>>>>> Off and on we've had discussions around the idea of "attribute groups". >>>>>> We've got some use cases that are crying out for such a thing[1], so I'd >>>>>> like to propose doing something concrete but simple for these for WF 9, >>>>>> ideally in the next month. >>>>>> >>>>>> A big part of my goal here is to ensure that whatever we do doesn't >>>>>> preclude something more advanced in any next generation management >>>>>> stuff, e.g. David's stuff. >>>>>> >>>>>> PART I Concepts >>>>>> >>>>>> 1) What is an attribute group? >>>>>> >>>>>> The "attribute group" concept I propose is simply a collection of >>>>>> attributes associated with the same resource type that are independently >>>>>> configurable but are statically declared to be conceptually related. The >>>>>> group has a name, and members. The name provides a brief indication of >>>>>> the nature of the relationship. >>>>>> >>>>>> The goal is to provide information to the user to help them better >>>>>> understand the relationship between attributes. In particular, >>>>>> management tools could use this information to visually present related >>>>>> attributes together, e.g. in a tab or other grouping widget in the web >>>>>> console. >>>>>> >>>>>> 2) What isn't an attribute group? >>>>>> >>>>>> Something relevant to writes. >>>>>> >>>>>> 3) Why would I use a child resource instead of an attribute group? >>>>>> >>>>>> Because the attributes control a discrete piece of functionality and you >>>>>> need to be able to turn that on or off as a unit. So you add/remove the >>>>>> resource. >>>>>> >>>>>> 4) Why would I use a complex attribute with a bunch of fields instead of >>>>>> n>1 simple attributes in a group. >>>>>> >>>>>> a) Because the attributes control a discrete piece of functionality and >>>>>> you need to be able to turn that off as a unit. So users can undefine >>>>>> the complex attribute. >>>>>> >>>>>> b) Because it's a common use case that modifications to n>1 of the >>>>>> fields should be done atomically and you don't want to force users to >>>>>> use a CLI batch. So you let them use write-attribute and specify the >>>>>> value of all the fields. >>>>> Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >>>>> Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions >>>>> >>>> >>>> On the branch of the thread where I'm discussing with Tomaz, he raised >>>> the same idea, which I think is a good one. I think a "write-attributes" >>>> with no relationship to attribute-group makes more sense though. >>> >>> I agree. I have always felt that we should allow more than level of >>> grouping. >> >> Did you mean "should NOT allow"? > > No, I mean multiple levels _should_ be allowed, just with multiple > qualifiers. Multiple attribute writing per resource _should_ be allowed > regardless of the depth or mixture of nesting. > > I.e. I should be able to do something like :write-attributes({"foo" = > 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard > necessary to deal with attribute group navigation. > Gotcha, and I agree. Thanks for clarifying. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 17:53:56 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 16:53:56 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <548858BD.1050901@redhat.com> References: <548754D5.9090402@redhat.com> <4BE8D3CE-356A-4CB8-BBDD-BAD655D6D168@redhat.com> <548858BD.1050901@redhat.com> Message-ID: <5488CF04.9090203@redhat.com> On 12/10/14, 8:29 AM, Brian Stansberry wrote: > On 12/9/14, 4:41 PM, Jason Greene wrote: >> This proposal is a great idea. Let?s do it :) >> > > I can probably have a branch with the "Proposed Work" bit, excluding the > CLI ls -l thing, done today or tomorrow. It went quicker than I thought. https://github.com/wildfly/wildfly-core/pull/391 https://issues.jboss.org/browse/WFCORE-457 > But the more important part is any discussion here. The CLI ls -l thing > I don't want to code yet because I don't have a strong feeling about > that solution. > >>> On Dec 9, 2014, at 2:00 PM, Brian Stansberry wrote: >>> >>> Off and on we've had discussions around the idea of "attribute groups". >>> We've got some use cases that are crying out for such a thing[1], so I'd >>> like to propose doing something concrete but simple for these for WF 9, >>> ideally in the next month. >>> >>> A big part of my goal here is to ensure that whatever we do doesn't >>> preclude something more advanced in any next generation management >>> stuff, e.g. David's stuff. >>> >>> PART I Concepts >>> >>> 1) What is an attribute group? >>> >>> The "attribute group" concept I propose is simply a collection of >>> attributes associated with the same resource type that are independently >>> configurable but are statically declared to be conceptually related. The >>> group has a name, and members. The name provides a brief indication of >>> the nature of the relationship. >>> >>> The goal is to provide information to the user to help them better >>> understand the relationship between attributes. In particular, >>> management tools could use this information to visually present related >>> attributes together, e.g. in a tab or other grouping widget in the web >>> console. >>> >>> 2) What isn't an attribute group? >>> >>> Something relevant to writes. >>> >>> 3) Why would I use a child resource instead of an attribute group? >>> >>> Because the attributes control a discrete piece of functionality and you >>> need to be able to turn that on or off as a unit. So you add/remove the >>> resource. >>> >>> 4) Why would I use a complex attribute with a bunch of fields instead of >>> n>1 simple attributes in a group. >>> >>> a) Because the attributes control a discrete piece of functionality and >>> you need to be able to turn that off as a unit. So users can undefine >>> the complex attribute. >>> >>> b) Because it's a common use case that modifications to n>1 of the >>> fields should be done atomically and you don't want to force users to >>> use a CLI batch. So you let them use write-attribute and specify the >>> value of all the fields. >>> >>> 5) Why would I use an attribute group instead of a child resource? >>> >>> Because requiring users to add a child resource just to set a bunch of >>> values that are really part of the config of the parent resource forces >>> them to use a CLI batch to correctly configure the parent resource. >>> >>> 6) Why would I use an attribute group instead a complex attribute? >>> >>> Because the various attributes should be independently configurable. In >>> particular, wiping out the config for all of them by simply undefining >>> the complex attribute isn't appropriate. >>> >>> PART II Proposed Work >>> >>> 1) The basics >>> >>> We add a piece of metadata to the read-resource-description output for >>> an attribute. Name is 'attribute-group', value type is ModelType.STRING, >>> value is the name of the group, with 'undefined' allowed. >>> >>> The group is simply the set of attributes that share the same string. >>> >>> To implement this, we add public String >>> AttributeDefinition.getAttributeGroup() and add support for setting it >>> to the relevant Builder. ReadResourceDescriptionHandler outputs the value. >>> >>> 2) XML parsing/marshalling >>> >>> Modify PersistentResourceXMLDescription such that attributes in an >>> attribute group get persisted in their own child element, whose name is >>> the name of the group. >>> >>> PersistentResourceXMLBuilder exposes a setter to allow users to turn >>> this on/off for that resource. Turning it off will allow the addition of >>> attribute group settings for a resource without requiring an immediate >>> corresponding xsd change. >>> >>> 3) Web console >>> >>> HAL can make use of the additional metadata at its leisure, and as it >>> becomes available. >>> >>> 4) Low level management API >>> >>> The output of read-resource and read-resource-description is modified >>> such that attributes are sorted by group name and then by attribute name. >>> >>> 5) CLI >>> >>> I'm not clear on exactly what to do here, but my instinct is the output >>> of the 'ls -l' command should be modified. Probably add a GROUP column >>> to the right and sort the order of attributes by group and then by >>> attribute name. >>> >>> PART III Other possible things to do >>> >>> A :read-attribute-group(name=) operation or an >>> "attribute-groups=[*]" param to :read-resource, to make it >>> convenient to read a set of attributes without needing to read the >>> entire resource. >>> >>> We could also consider adding an "attribute-groups" section to the >>> read-resource-description output, where a fuller i18n text description >>> of the meaning of the group could be written. If we do this we should >>> probably do it in WF 9 as it will likely add some sort of requirement to >>> subsystem authors that we expose right from the start. >>> >>> >>> If you're still awake, comments as always are appreciated. >>> >>> -- >>> Brian Stansberry >>> Senior Principal Software Engineer >>> JBoss by Red Hat >>> >>> [1] For example, the JDKORB pull request at >>> https://github.com/wildfly/wildfly/pull/7008 uses child resources in a >>> number of places where it seems like attribute groups are a better fit. >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 18:06:11 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 17:06:11 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <20327C4E-CBE3-4B4A-B678-38670E73138C@redhat.com> References: <548754D5.9090402@redhat.com> <20327C4E-CBE3-4B4A-B678-38670E73138C@redhat.com> Message-ID: <5488D1E3.1070304@redhat.com> https://issues.jboss.org/browse/WFCORE-458 for the read-attribute-group bits. On 12/10/14, 1:04 AM, Heiko Braun wrote: > +1 i am all for it. Including read-attribute-group(). But i would as well add a read-attribute-group-names() operation to complete the picture. > > > > >> Am 09.12.2014 um 21:00 schrieb Brian Stansberry : >> >> read-attribute-group -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Wed Dec 10 18:14:42 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 10 Dec 2014 17:14:42 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488885F.5030103@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> Message-ID: <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> > On Dec 10, 2014, at 11:52 AM, Brian Stansberry wrote: > > On 12/10/14, 11:44 AM, David M. Lloyd wrote: >> Forgot to hit "reply to list" on this one. >> >> On 12/10/2014 10:30 AM, Brian Stansberry wrote: >>> On 12/10/14, 10:06 AM, David M. Lloyd wrote: >>>> On 12/10/2014 09:52 AM, Brian Stansberry wrote: >>>>> On 12/10/14, 9:22 AM, Kabir Khan wrote: >>>>>> >>>>>>> On 9 Dec 2014, at 21:00, Brian Stansberry wrote: >>>>>>> >>>>>>> Off and on we've had discussions around the idea of "attribute groups". >>>>>>> We've got some use cases that are crying out for such a thing[1], so I'd >>>>>>> like to propose doing something concrete but simple for these for WF 9, >>>>>>> ideally in the next month. >>>>>>> >>>>>>> A big part of my goal here is to ensure that whatever we do doesn't >>>>>>> preclude something more advanced in any next generation management >>>>>>> stuff, e.g. David's stuff. >>>>>>> >>>>>>> PART I Concepts >>>>>>> >>>>>>> 1) What is an attribute group? >>>>>>> >>>>>>> The "attribute group" concept I propose is simply a collection of >>>>>>> attributes associated with the same resource type that are independently >>>>>>> configurable but are statically declared to be conceptually related. The >>>>>>> group has a name, and members. The name provides a brief indication of >>>>>>> the nature of the relationship. >>>>>>> >>>>>>> The goal is to provide information to the user to help them better >>>>>>> understand the relationship between attributes. In particular, >>>>>>> management tools could use this information to visually present related >>>>>>> attributes together, e.g. in a tab or other grouping widget in the web >>>>>>> console. >>>>>>> >>>>>>> 2) What isn't an attribute group? >>>>>>> >>>>>>> Something relevant to writes. >>>>>>> >>>>>>> 3) Why would I use a child resource instead of an attribute group? >>>>>>> >>>>>>> Because the attributes control a discrete piece of functionality and you >>>>>>> need to be able to turn that on or off as a unit. So you add/remove the >>>>>>> resource. >>>>>>> >>>>>>> 4) Why would I use a complex attribute with a bunch of fields instead of >>>>>>> n>1 simple attributes in a group. >>>>>>> >>>>>>> a) Because the attributes control a discrete piece of functionality and >>>>>>> you need to be able to turn that off as a unit. So users can undefine >>>>>>> the complex attribute. >>>>>>> >>>>>>> b) Because it's a common use case that modifications to n>1 of the >>>>>>> fields should be done atomically and you don't want to force users to >>>>>>> use a CLI batch. So you let them use write-attribute and specify the >>>>>>> value of all the fields. >>>>>> Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >>>>>> Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions >>>>>> >>>>> >>>>> On the branch of the thread where I'm discussing with Tomaz, he raised >>>>> the same idea, which I think is a good one. I think a "write-attributes" >>>>> with no relationship to attribute-group makes more sense though. >>>> >>>> I agree. I have always felt that we should allow more than level of >>>> grouping. >>> >>> Did you mean "should NOT allow"? >> >> No, I mean multiple levels _should_ be allowed, just with multiple >> qualifiers. Multiple attribute writing per resource _should_ be allowed >> regardless of the depth or mixture of nesting. >> >> I.e. I should be able to do something like :write-attributes({"foo" = >> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard >> necessary to deal with attribute group navigation. >> > > Gotcha, and I agree. Thanks for clarifying. Hmm that nested syntax is an orthogonal feature IMO. I think that requires a lot more thought, as its basically inventing another nested dmr-path grammar. Not to say that we shouldn?t have that I just see rabbit hole there. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Wed Dec 10 18:27:06 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 17:27:06 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> Message-ID: <5488D6CA.9020903@redhat.com> On 12/10/14, 5:14 PM, Jason Greene wrote: > >> On Dec 10, 2014, at 11:52 AM, Brian Stansberry wrote: >> >> On 12/10/14, 11:44 AM, David M. Lloyd wrote: >>> Forgot to hit "reply to list" on this one. >>> >>> On 12/10/2014 10:30 AM, Brian Stansberry wrote: >>>> On 12/10/14, 10:06 AM, David M. Lloyd wrote: >>>>> On 12/10/2014 09:52 AM, Brian Stansberry wrote: >>>>>> On 12/10/14, 9:22 AM, Kabir Khan wrote: >>>>>>> >>>>>>>> On 9 Dec 2014, at 21:00, Brian Stansberry wrote: >>>>>>>> >>>>>>>> Off and on we've had discussions around the idea of "attribute groups". >>>>>>>> We've got some use cases that are crying out for such a thing[1], so I'd >>>>>>>> like to propose doing something concrete but simple for these for WF 9, >>>>>>>> ideally in the next month. >>>>>>>> >>>>>>>> A big part of my goal here is to ensure that whatever we do doesn't >>>>>>>> preclude something more advanced in any next generation management >>>>>>>> stuff, e.g. David's stuff. >>>>>>>> >>>>>>>> PART I Concepts >>>>>>>> >>>>>>>> 1) What is an attribute group? >>>>>>>> >>>>>>>> The "attribute group" concept I propose is simply a collection of >>>>>>>> attributes associated with the same resource type that are independently >>>>>>>> configurable but are statically declared to be conceptually related. The >>>>>>>> group has a name, and members. The name provides a brief indication of >>>>>>>> the nature of the relationship. >>>>>>>> >>>>>>>> The goal is to provide information to the user to help them better >>>>>>>> understand the relationship between attributes. In particular, >>>>>>>> management tools could use this information to visually present related >>>>>>>> attributes together, e.g. in a tab or other grouping widget in the web >>>>>>>> console. >>>>>>>> >>>>>>>> 2) What isn't an attribute group? >>>>>>>> >>>>>>>> Something relevant to writes. >>>>>>>> >>>>>>>> 3) Why would I use a child resource instead of an attribute group? >>>>>>>> >>>>>>>> Because the attributes control a discrete piece of functionality and you >>>>>>>> need to be able to turn that on or off as a unit. So you add/remove the >>>>>>>> resource. >>>>>>>> >>>>>>>> 4) Why would I use a complex attribute with a bunch of fields instead of >>>>>>>> n>1 simple attributes in a group. >>>>>>>> >>>>>>>> a) Because the attributes control a discrete piece of functionality and >>>>>>>> you need to be able to turn that off as a unit. So users can undefine >>>>>>>> the complex attribute. >>>>>>>> >>>>>>>> b) Because it's a common use case that modifications to n>1 of the >>>>>>>> fields should be done atomically and you don't want to force users to >>>>>>>> use a CLI batch. So you let them use write-attribute and specify the >>>>>>>> value of all the fields. >>>>>>> Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >>>>>>> Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions >>>>>>> >>>>>> >>>>>> On the branch of the thread where I'm discussing with Tomaz, he raised >>>>>> the same idea, which I think is a good one. I think a "write-attributes" >>>>>> with no relationship to attribute-group makes more sense though. >>>>> >>>>> I agree. I have always felt that we should allow more than level of >>>>> grouping. >>>> >>>> Did you mean "should NOT allow"? >>> >>> No, I mean multiple levels _should_ be allowed, just with multiple >>> qualifiers. Multiple attribute writing per resource _should_ be allowed >>> regardless of the depth or mixture of nesting. >>> >>> I.e. I should be able to do something like :write-attributes({"foo" = >>> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard >>> necessary to deal with attribute group navigation. >>> >> >> Gotcha, and I agree. Thanks for clarifying. > > Hmm that nested syntax is an orthogonal feature IMO. I think that requires a lot more thought, as its basically inventing another nested dmr-path grammar. Not to say that we shouldn?t have that I just see rabbit hole there. > Weird timing. I'm writing the JIRA for "write-attributes", trying to be precise, and I just now hit that rabbit hole. We already have the syntax, but it's used in the *value* of the "name" parameter to "write-attribute". Here we are using it in the parameter *name*. That makes it impractical to have a proper list of request-properties (aka params) in the read-operation-description output for the write-attributes op registered against a given address. Without that syntax, the parameter list would look much like the parameters for the resource's "add" operation. Further down the rabbit hole, thinking about this earlier I realized the read-operation-description output for the "write-attribute" operation is not as good as it could be. For any given resource, the description of the "name" parameter could/should include the legal values, i.e. the names of the writable attributes. We don't do that, and now we really can't. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Wed Dec 10 18:34:52 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 10 Dec 2014 17:34:52 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488D6CA.9020903@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> Message-ID: <5488D89C.1040309@redhat.com> On 12/10/2014 05:27 PM, Brian Stansberry wrote: > On 12/10/14, 5:14 PM, Jason Greene wrote: >>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry wrote: >>> On 12/10/14, 11:44 AM, David M. Lloyd wrote: >>>> I.e. I should be able to do something like :write-attributes({"foo" = >>>> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard >>>> necessary to deal with attribute group navigation. >>> >>> Gotcha, and I agree. Thanks for clarifying. >> >> Hmm that nested syntax is an orthogonal feature IMO. I think that requires a lot more thought, as its basically inventing another nested dmr-path grammar. Not to say that we shouldn?t have that I just see rabbit hole there. > > Weird timing. I'm writing the JIRA for "write-attributes", trying to be > precise, and I just now hit that rabbit hole. > > We already have the syntax, but it's used in the *value* of the "name" > parameter to "write-attribute". Here we are using it in the parameter > *name*. That makes it impractical to have a proper list of > request-properties (aka params) in the read-operation-description output > for the write-attributes op registered against a given address. Why does it make a difference? The attribute names would be "a.b.c" instead of just "a", but I don't see that as an impracticality. > Withoutthat syntax, the parameter list would look much like the parameters for > the resource's "add" operation. Why is that a problem? It's essentially the same thing in most cases, isn't it? > Further down the rabbit hole, thinking about this earlier I realized the > read-operation-description output for the "write-attribute" operation is > not as good as it could be. For any given resource, the description of > the "name" parameter could/should include the legal values, i.e. the > names of the writable attributes. We don't do that, and now we really can't. Why not? -- - DML From brian.stansberry at redhat.com Wed Dec 10 18:35:11 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 17:35:11 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488D6CA.9020903@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> Message-ID: <5488D8AF.7090200@redhat.com> On 12/10/14, 5:27 PM, Brian Stansberry wrote: > On 12/10/14, 5:14 PM, Jason Greene wrote: >> >>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry >>> wrote: >>> >>> On 12/10/14, 11:44 AM, David M. Lloyd wrote: >>>> Forgot to hit "reply to list" on this one. >>>> >>>> On 12/10/2014 10:30 AM, Brian Stansberry wrote: >>>>> On 12/10/14, 10:06 AM, David M. Lloyd wrote: >>>>>> On 12/10/2014 09:52 AM, Brian Stansberry wrote: >>>>>>> On 12/10/14, 9:22 AM, Kabir Khan wrote: >>>>>>>> >>>>>>>>> On 9 Dec 2014, at 21:00, Brian Stansberry >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Off and on we've had discussions around the idea of "attribute >>>>>>>>> groups". >>>>>>>>> We've got some use cases that are crying out for such a >>>>>>>>> thing[1], so I'd >>>>>>>>> like to propose doing something concrete but simple for these >>>>>>>>> for WF 9, >>>>>>>>> ideally in the next month. >>>>>>>>> >>>>>>>>> A big part of my goal here is to ensure that whatever we do >>>>>>>>> doesn't >>>>>>>>> preclude something more advanced in any next generation management >>>>>>>>> stuff, e.g. David's stuff. >>>>>>>>> >>>>>>>>> PART I Concepts >>>>>>>>> >>>>>>>>> 1) What is an attribute group? >>>>>>>>> >>>>>>>>> The "attribute group" concept I propose is simply a collection of >>>>>>>>> attributes associated with the same resource type that are >>>>>>>>> independently >>>>>>>>> configurable but are statically declared to be conceptually >>>>>>>>> related. The >>>>>>>>> group has a name, and members. The name provides a brief >>>>>>>>> indication of >>>>>>>>> the nature of the relationship. >>>>>>>>> >>>>>>>>> The goal is to provide information to the user to help them better >>>>>>>>> understand the relationship between attributes. In particular, >>>>>>>>> management tools could use this information to visually present >>>>>>>>> related >>>>>>>>> attributes together, e.g. in a tab or other grouping widget in >>>>>>>>> the web >>>>>>>>> console. >>>>>>>>> >>>>>>>>> 2) What isn't an attribute group? >>>>>>>>> >>>>>>>>> Something relevant to writes. >>>>>>>>> >>>>>>>>> 3) Why would I use a child resource instead of an attribute group? >>>>>>>>> >>>>>>>>> Because the attributes control a discrete piece of >>>>>>>>> functionality and you >>>>>>>>> need to be able to turn that on or off as a unit. So you >>>>>>>>> add/remove the >>>>>>>>> resource. >>>>>>>>> >>>>>>>>> 4) Why would I use a complex attribute with a bunch of fields >>>>>>>>> instead of >>>>>>>>> n>1 simple attributes in a group. >>>>>>>>> >>>>>>>>> a) Because the attributes control a discrete piece of >>>>>>>>> functionality and >>>>>>>>> you need to be able to turn that off as a unit. So users can >>>>>>>>> undefine >>>>>>>>> the complex attribute. >>>>>>>>> >>>>>>>>> b) Because it's a common use case that modifications to n>1 of the >>>>>>>>> fields should be done atomically and you don't want to force >>>>>>>>> users to >>>>>>>>> use a CLI batch. So you let them use write-attribute and >>>>>>>>> specify the >>>>>>>>> value of all the fields. >>>>>>>> Why not something along the lines of >>>>>>>> :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >>>>>>>> Internally that could create a composite for us, giving complex >>>>>>>> attribute functionality while avoiding the messy resource >>>>>>>> descriptions >>>>>>>> >>>>>>> >>>>>>> On the branch of the thread where I'm discussing with Tomaz, he >>>>>>> raised >>>>>>> the same idea, which I think is a good one. I think a >>>>>>> "write-attributes" >>>>>>> with no relationship to attribute-group makes more sense though. >>>>>> >>>>>> I agree. I have always felt that we should allow more than level of >>>>>> grouping. >>>>> >>>>> Did you mean "should NOT allow"? >>>> >>>> No, I mean multiple levels _should_ be allowed, just with multiple >>>> qualifiers. Multiple attribute writing per resource _should_ be >>>> allowed >>>> regardless of the depth or mixture of nesting. >>>> >>>> I.e. I should be able to do something like :write-attributes({"foo" = >>>> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard >>>> necessary to deal with attribute group navigation. >>>> >>> >>> Gotcha, and I agree. Thanks for clarifying. >> >> Hmm that nested syntax is an orthogonal feature IMO. I think that >> requires a lot more thought, as its basically inventing another nested >> dmr-path grammar. Not to say that we shouldn?t have that I just see >> rabbit hole there. >> > > Weird timing. I'm writing the JIRA for "write-attributes", trying to be > precise, and I just now hit that rabbit hole. > > We already have the syntax, but it's used in the *value* of the "name" > parameter to "write-attribute". Here we are using it in the parameter > *name*. That makes it impractical to have a proper list of > request-properties (aka params) in the read-operation-description output > for the write-attributes op registered against a given address. Without > that syntax, the parameter list would look much like the parameters for > the resource's "add" operation. > > Further down the rabbit hole, thinking about this earlier I realized the > read-operation-description output for the "write-attribute" operation is > not as good as it could be. For any given resource, the description of > the "name" parameter could/should include the legal values, i.e. the > names of the writable attributes. We don't do that, and now we really > can't. > I gave up writing up the JIRA, as I want it to be precise and it can't be precise enough until we have a good solution to this question. An ugly one is: :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}]) That's a lot more confusing and verbose than :write-attributes(foo=123,bar.baz.zap=hello) -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Wed Dec 10 18:37:19 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 10 Dec 2014 17:37:19 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488D8AF.7090200@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> <5488D8AF.7090200@redhat.com> Message-ID: <5488D92F.8040903@redhat.com> On 12/10/2014 05:35 PM, Brian Stansberry wrote: > On 12/10/14, 5:27 PM, Brian Stansberry wrote: >> On 12/10/14, 5:14 PM, Jason Greene wrote: >>> >>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry >>>> wrote: >>>> >>>> On 12/10/14, 11:44 AM, David M. Lloyd wrote: >>>>> Forgot to hit "reply to list" on this one. >>>>> >>>>> On 12/10/2014 10:30 AM, Brian Stansberry wrote: >>>>>> On 12/10/14, 10:06 AM, David M. Lloyd wrote: >>>>>>> On 12/10/2014 09:52 AM, Brian Stansberry wrote: >>>>>>>> On 12/10/14, 9:22 AM, Kabir Khan wrote: >>>>>>>>> >>>>>>>>>> On 9 Dec 2014, at 21:00, Brian Stansberry >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Off and on we've had discussions around the idea of "attribute >>>>>>>>>> groups". >>>>>>>>>> We've got some use cases that are crying out for such a >>>>>>>>>> thing[1], so I'd >>>>>>>>>> like to propose doing something concrete but simple for these >>>>>>>>>> for WF 9, >>>>>>>>>> ideally in the next month. >>>>>>>>>> >>>>>>>>>> A big part of my goal here is to ensure that whatever we do >>>>>>>>>> doesn't >>>>>>>>>> preclude something more advanced in any next generation management >>>>>>>>>> stuff, e.g. David's stuff. >>>>>>>>>> >>>>>>>>>> PART I Concepts >>>>>>>>>> >>>>>>>>>> 1) What is an attribute group? >>>>>>>>>> >>>>>>>>>> The "attribute group" concept I propose is simply a collection of >>>>>>>>>> attributes associated with the same resource type that are >>>>>>>>>> independently >>>>>>>>>> configurable but are statically declared to be conceptually >>>>>>>>>> related. The >>>>>>>>>> group has a name, and members. The name provides a brief >>>>>>>>>> indication of >>>>>>>>>> the nature of the relationship. >>>>>>>>>> >>>>>>>>>> The goal is to provide information to the user to help them better >>>>>>>>>> understand the relationship between attributes. In particular, >>>>>>>>>> management tools could use this information to visually present >>>>>>>>>> related >>>>>>>>>> attributes together, e.g. in a tab or other grouping widget in >>>>>>>>>> the web >>>>>>>>>> console. >>>>>>>>>> >>>>>>>>>> 2) What isn't an attribute group? >>>>>>>>>> >>>>>>>>>> Something relevant to writes. >>>>>>>>>> >>>>>>>>>> 3) Why would I use a child resource instead of an attribute group? >>>>>>>>>> >>>>>>>>>> Because the attributes control a discrete piece of >>>>>>>>>> functionality and you >>>>>>>>>> need to be able to turn that on or off as a unit. So you >>>>>>>>>> add/remove the >>>>>>>>>> resource. >>>>>>>>>> >>>>>>>>>> 4) Why would I use a complex attribute with a bunch of fields >>>>>>>>>> instead of >>>>>>>>>> n>1 simple attributes in a group. >>>>>>>>>> >>>>>>>>>> a) Because the attributes control a discrete piece of >>>>>>>>>> functionality and >>>>>>>>>> you need to be able to turn that off as a unit. So users can >>>>>>>>>> undefine >>>>>>>>>> the complex attribute. >>>>>>>>>> >>>>>>>>>> b) Because it's a common use case that modifications to n>1 of the >>>>>>>>>> fields should be done atomically and you don't want to force >>>>>>>>>> users to >>>>>>>>>> use a CLI batch. So you let them use write-attribute and >>>>>>>>>> specify the >>>>>>>>>> value of all the fields. >>>>>>>>> Why not something along the lines of >>>>>>>>> :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >>>>>>>>> Internally that could create a composite for us, giving complex >>>>>>>>> attribute functionality while avoiding the messy resource >>>>>>>>> descriptions >>>>>>>>> >>>>>>>> >>>>>>>> On the branch of the thread where I'm discussing with Tomaz, he >>>>>>>> raised >>>>>>>> the same idea, which I think is a good one. I think a >>>>>>>> "write-attributes" >>>>>>>> with no relationship to attribute-group makes more sense though. >>>>>>> >>>>>>> I agree. I have always felt that we should allow more than level of >>>>>>> grouping. >>>>>> >>>>>> Did you mean "should NOT allow"? >>>>> >>>>> No, I mean multiple levels _should_ be allowed, just with multiple >>>>> qualifiers. Multiple attribute writing per resource _should_ be >>>>> allowed >>>>> regardless of the depth or mixture of nesting. >>>>> >>>>> I.e. I should be able to do something like :write-attributes({"foo" = >>>>> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard >>>>> necessary to deal with attribute group navigation. >>>>> >>>> >>>> Gotcha, and I agree. Thanks for clarifying. >>> >>> Hmm that nested syntax is an orthogonal feature IMO. I think that >>> requires a lot more thought, as its basically inventing another nested >>> dmr-path grammar. Not to say that we shouldn?t have that I just see >>> rabbit hole there. >>> >> >> Weird timing. I'm writing the JIRA for "write-attributes", trying to be >> precise, and I just now hit that rabbit hole. >> >> We already have the syntax, but it's used in the *value* of the "name" >> parameter to "write-attribute". Here we are using it in the parameter >> *name*. That makes it impractical to have a proper list of >> request-properties (aka params) in the read-operation-description output >> for the write-attributes op registered against a given address. Without >> that syntax, the parameter list would look much like the parameters for >> the resource's "add" operation. >> >> Further down the rabbit hole, thinking about this earlier I realized the >> read-operation-description output for the "write-attribute" operation is >> not as good as it could be. For any given resource, the description of >> the "name" parameter could/should include the legal values, i.e. the >> names of the writable attributes. We don't do that, and now we really >> can't. >> > > I gave up writing up the JIRA, as I want it to be precise and it can't > be precise enough until we have a good solution to this question. An > ugly one is: > > :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}]) > > That's a lot more confusing and verbose than > > :write-attributes(foo=123,bar.baz.zap=hello) I guess I missed a beat; why can't we do the latter? Is it because of the way we describe operations? IMO this operation should be on an equal footing with adding resources and we should have a uniform means to describe it as such. -- - DML From brian.stansberry at redhat.com Wed Dec 10 18:38:49 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 17:38:49 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488D89C.1040309@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> <5488D89C.1040309@redhat.com> Message-ID: <5488D989.8060307@redhat.com> On 12/10/14, 5:34 PM, David M. Lloyd wrote: > On 12/10/2014 05:27 PM, Brian Stansberry wrote: >> On 12/10/14, 5:14 PM, Jason Greene wrote: >>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry wrote: >>>> On 12/10/14, 11:44 AM, David M. Lloyd wrote: >>>>> I.e. I should be able to do something like :write-attributes({"foo" = >>>>> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard >>>>> necessary to deal with attribute group navigation. >>>> >>>> Gotcha, and I agree. Thanks for clarifying. >>> >>> Hmm that nested syntax is an orthogonal feature IMO. I think that requires a lot more thought, as its basically inventing another nested dmr-path grammar. Not to say that we shouldn?t have that I just see rabbit hole there. >> >> Weird timing. I'm writing the JIRA for "write-attributes", trying to be >> precise, and I just now hit that rabbit hole. >> >> We already have the syntax, but it's used in the *value* of the "name" >> parameter to "write-attribute". Here we are using it in the parameter >> *name*. That makes it impractical to have a proper list of >> request-properties (aka params) in the read-operation-description output >> for the write-attributes op registered against a given address. > > Why does it make a difference? The attribute names would be "a.b.c" > instead of just "a", but I don't see that as an impracticality. > IIRC the syntax also allows list indexing, so it's not static. >> Withoutthat syntax, the parameter list would look much like the parameters for >> the resource's "add" operation. > > Why is that a problem? It's essentially the same thing in most cases, > isn't it? > >> Further down the rabbit hole, thinking about this earlier I realized the >> read-operation-description output for the "write-attribute" operation is >> not as good as it could be. For any given resource, the description of >> the "name" parameter could/should include the legal values, i.e. the >> names of the writable attributes. We don't do that, and now we really can't. > > Why not? > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Dec 10 19:02:51 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 10 Dec 2014 18:02:51 -0600 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488D92F.8040903@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> <5488D8AF.7090200@redhat.com> <5488D92F.8040903@redhat.com> Message-ID: <5488DF2B.6090800@redhat.com> On 12/10/14, 5:37 PM, David M. Lloyd wrote: > On 12/10/2014 05:35 PM, Brian Stansberry wrote: >> On 12/10/14, 5:27 PM, Brian Stansberry wrote: >>> On 12/10/14, 5:14 PM, Jason Greene wrote: >>>> >>>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry >>>>> wrote: >>>>> >>>>> On 12/10/14, 11:44 AM, David M. Lloyd wrote: >>>>>> Forgot to hit "reply to list" on this one. >>>>>> >>>>>> On 12/10/2014 10:30 AM, Brian Stansberry wrote: >>>>>>> On 12/10/14, 10:06 AM, David M. Lloyd wrote: >>>>>>>> On 12/10/2014 09:52 AM, Brian Stansberry wrote: >>>>>>>>> On 12/10/14, 9:22 AM, Kabir Khan wrote: >>>>>>>>>> >>>>>>>>>>> On 9 Dec 2014, at 21:00, Brian Stansberry >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Off and on we've had discussions around the idea of "attribute >>>>>>>>>>> groups". >>>>>>>>>>> We've got some use cases that are crying out for such a >>>>>>>>>>> thing[1], so I'd >>>>>>>>>>> like to propose doing something concrete but simple for these >>>>>>>>>>> for WF 9, >>>>>>>>>>> ideally in the next month. >>>>>>>>>>> >>>>>>>>>>> A big part of my goal here is to ensure that whatever we do >>>>>>>>>>> doesn't >>>>>>>>>>> preclude something more advanced in any next generation management >>>>>>>>>>> stuff, e.g. David's stuff. >>>>>>>>>>> >>>>>>>>>>> PART I Concepts >>>>>>>>>>> >>>>>>>>>>> 1) What is an attribute group? >>>>>>>>>>> >>>>>>>>>>> The "attribute group" concept I propose is simply a collection of >>>>>>>>>>> attributes associated with the same resource type that are >>>>>>>>>>> independently >>>>>>>>>>> configurable but are statically declared to be conceptually >>>>>>>>>>> related. The >>>>>>>>>>> group has a name, and members. The name provides a brief >>>>>>>>>>> indication of >>>>>>>>>>> the nature of the relationship. >>>>>>>>>>> >>>>>>>>>>> The goal is to provide information to the user to help them better >>>>>>>>>>> understand the relationship between attributes. In particular, >>>>>>>>>>> management tools could use this information to visually present >>>>>>>>>>> related >>>>>>>>>>> attributes together, e.g. in a tab or other grouping widget in >>>>>>>>>>> the web >>>>>>>>>>> console. >>>>>>>>>>> >>>>>>>>>>> 2) What isn't an attribute group? >>>>>>>>>>> >>>>>>>>>>> Something relevant to writes. >>>>>>>>>>> >>>>>>>>>>> 3) Why would I use a child resource instead of an attribute group? >>>>>>>>>>> >>>>>>>>>>> Because the attributes control a discrete piece of >>>>>>>>>>> functionality and you >>>>>>>>>>> need to be able to turn that on or off as a unit. So you >>>>>>>>>>> add/remove the >>>>>>>>>>> resource. >>>>>>>>>>> >>>>>>>>>>> 4) Why would I use a complex attribute with a bunch of fields >>>>>>>>>>> instead of >>>>>>>>>>> n>1 simple attributes in a group. >>>>>>>>>>> >>>>>>>>>>> a) Because the attributes control a discrete piece of >>>>>>>>>>> functionality and >>>>>>>>>>> you need to be able to turn that off as a unit. So users can >>>>>>>>>>> undefine >>>>>>>>>>> the complex attribute. >>>>>>>>>>> >>>>>>>>>>> b) Because it's a common use case that modifications to n>1 of the >>>>>>>>>>> fields should be done atomically and you don't want to force >>>>>>>>>>> users to >>>>>>>>>>> use a CLI batch. So you let them use write-attribute and >>>>>>>>>>> specify the >>>>>>>>>>> value of all the fields. >>>>>>>>>> Why not something along the lines of >>>>>>>>>> :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >>>>>>>>>> Internally that could create a composite for us, giving complex >>>>>>>>>> attribute functionality while avoiding the messy resource >>>>>>>>>> descriptions >>>>>>>>>> >>>>>>>>> >>>>>>>>> On the branch of the thread where I'm discussing with Tomaz, he >>>>>>>>> raised >>>>>>>>> the same idea, which I think is a good one. I think a >>>>>>>>> "write-attributes" >>>>>>>>> with no relationship to attribute-group makes more sense though. >>>>>>>> >>>>>>>> I agree. I have always felt that we should allow more than level of >>>>>>>> grouping. >>>>>>> >>>>>>> Did you mean "should NOT allow"? >>>>>> >>>>>> No, I mean multiple levels _should_ be allowed, just with multiple >>>>>> qualifiers. Multiple attribute writing per resource _should_ be >>>>>> allowed >>>>>> regardless of the depth or mixture of nesting. >>>>>> >>>>>> I.e. I should be able to do something like :write-attributes({"foo" = >>>>>> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard >>>>>> necessary to deal with attribute group navigation. >>>>>> >>>>> >>>>> Gotcha, and I agree. Thanks for clarifying. >>>> >>>> Hmm that nested syntax is an orthogonal feature IMO. I think that >>>> requires a lot more thought, as its basically inventing another nested >>>> dmr-path grammar. Not to say that we shouldn?t have that I just see >>>> rabbit hole there. >>>> >>> >>> Weird timing. I'm writing the JIRA for "write-attributes", trying to be >>> precise, and I just now hit that rabbit hole. >>> >>> We already have the syntax, but it's used in the *value* of the "name" >>> parameter to "write-attribute". Here we are using it in the parameter >>> *name*. That makes it impractical to have a proper list of >>> request-properties (aka params) in the read-operation-description output >>> for the write-attributes op registered against a given address. Without >>> that syntax, the parameter list would look much like the parameters for >>> the resource's "add" operation. >>> >>> Further down the rabbit hole, thinking about this earlier I realized the >>> read-operation-description output for the "write-attribute" operation is >>> not as good as it could be. For any given resource, the description of >>> the "name" parameter could/should include the legal values, i.e. the >>> names of the writable attributes. We don't do that, and now we really >>> can't. >>> >> >> I gave up writing up the JIRA, as I want it to be precise and it can't >> be precise enough until we have a good solution to this question. An >> ugly one is: >> >> :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}]) >> >> That's a lot more confusing and verbose than >> >> :write-attributes(foo=123,bar.baz.zap=hello) > > I guess I missed a beat; why can't we do the latter? Is it because of > the way we describe operations? IMO this operation should be on an > equal footing with adding resources and we should have a uniform means > to describe it as such. > We describe the parameters to operations, including their names, and for all cases up to now those are easily and statically known. The CLI validates the parameter names used in low-level ops against the description. This can be solved by analyzing any complex attributes and outputing all valid paths, using syntax like [] or [?] or [*] to indicate path segments that represent elements in a list. We don't allow '.', '[' or ']' in attribute/field names, so the presence of the [ is enough to indicate that a list element is being described; the remaining ']', '?]' or '*]' are just to improve readability. I prefer a simple '[]'. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Thu Dec 11 02:21:09 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 11 Dec 2014 08:21:09 +0100 Subject: [wildfly-dev] Management console web application In-Reply-To: References: Message-ID: <83426235-0CC0-47A9-A152-C3812C474BB7@redhat.com> Here?s another design proposal to improve the domain overview, especially for larger domains: http://lists.jboss.org/pipermail/wildfly-dev/2014-July/002627.html Maybe something to consider? Regards, Heiko > On 09 Dec 2014, at 12:42, Dev Ops wrote: > > Hi, > thanks for pointing me to the github repo. > > I need to do a couple of things: > provide a graphical and complete view of all server-groups - along with the hosts - something like the following http://bl.ocks.org/mbostock/1062288 > provide a button to download the deployed application; > Next would be extending point 2. by providing different colors for different metric values. > Likely, heap memory metric going to saturation, the balloon would be colored has almost red (#cc0000)... every hosts could have its own metric (heap memory, cpu usage, connection pool statistics, etc...). > Alerts and notifications are not needed, as there are already other software accomplishing these tasks (nagios, jon, etc...). > > Regards, > DevOps guy > > > On Tue, Dec 9, 2014 at 11:13 AM, Harald Pehl > wrote: > The source code for the management console lives in its own repository at https://github.com/hal/core > > I'm curious, what kind of customization do you have in mind? > > .: Harald > >> Am 09.12.2014 um 11:06 schrieb Dev Ops >: >> >> Hi all, >> where do I find the source of the web application which provides the Management console? >> >> I need to add something to it, but I don't know where to get the source. >> >> >> TIA, >> DevOps guy >> _______________________________________________ >> 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/20141211/f0e28446/attachment-0001.html From tomaz.cerar at gmail.com Thu Dec 11 08:42:39 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 11 Dec 2014 14:42:39 +0100 Subject: [wildfly-dev] Management model attribute groups In-Reply-To: <5488D92F.8040903@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> <5488D8AF.7090200@redhat.com> <5488D92F.8040903@redhat.com> Message-ID: On Thu, Dec 11, 2014 at 12:37 AM, David M. Lloyd wrote: > I guess I missed a beat; why can't we do the latter? Is it because of > the way we describe operations? IMO this operation should be on an > equal footing with adding resources and we should have a uniform means > to describe it as such. > I think what you are looking for is being addressed as part of different issue. We had discussion about it few months back. The proposed behavior is described here https://gist.github.com/ctomc/91055a6f4e7502dcd130 The first part about collections operations is already done the extended write/read-attribute syntax not yet. Jira for it https://issues.jboss.org/browse/WFCORE-460 Is this what you are aiming for? as :write-attributes operation we are talking about is different thing, just allowing us to atomically update more than one attribute. The extended manipulation syntax would also apply to this. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141211/fce03835/attachment.html From claudio at claudius.com.br Thu Dec 11 08:59:25 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Thu, 11 Dec 2014 11:59:25 -0200 Subject: [wildfly-dev] Management console web application In-Reply-To: <83426235-0CC0-47A9-A152-C3812C474BB7@redhat.com> References: <83426235-0CC0-47A9-A152-C3812C474BB7@redhat.com> Message-ID: On Thu, Dec 11, 2014 at 5:21 AM, Heiko Braun wrote: > Here's another design proposal to improve the domain overview, especially > for larger domains: > > http://lists.jboss.org/pipermail/wildfly-dev/2014-July/002627.html What was the result for that proposal ? Do you consider to implement it ? -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From emartins at redhat.com Thu Dec 11 09:33:27 2014 From: emartins at redhat.com (Eduardo Martins) Date: Thu, 11 Dec 2014 14:33:27 +0000 Subject: [wildfly-dev] New WildFly Quickstart available Message-ID: <607A8A6A-E382-4299-B2E7-3275796FFBDE@redhat.com> See http://eduardomartins.me/2014/12/javaee-thread-racing ?E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141211/1fc9f32a/attachment.html From hbraun at redhat.com Thu Dec 11 09:53:11 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 11 Dec 2014 15:53:11 +0100 Subject: [wildfly-dev] Management console web application In-Reply-To: References: <83426235-0CC0-47A9-A152-C3812C474BB7@redhat.com> Message-ID: <265015DE-8386-48DB-8FBA-23E59C16A99B@redhat.com> we didn?t conclude on it, but I guess that we will move into that direction, yes. > On 11 Dec 2014, at 14:59, Claudio Miranda wrote: > > What was the result for that proposal ? Do you consider to implement it ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141211/00b66563/attachment.html From brian.stansberry at redhat.com Thu Dec 11 16:09:08 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 11 Dec 2014 15:09:08 -0600 Subject: [wildfly-dev] A write-attributes op, and dealing with complex attribute paths In-Reply-To: <5488DF2B.6090800@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> <5488D8AF.7090200@redhat.com> <5488D92F.8040903@redhat.com> <5488DF2B.6090800@redhat.com> Message-ID: <548A07F4.5000001@redhat.com> This is a separate topic from the previous thread, so renaming. Bottom-post below... On 12/10/14, 6:02 PM, Brian Stansberry wrote: > On 12/10/14, 5:37 PM, David M. Lloyd wrote: >> On 12/10/2014 05:35 PM, Brian Stansberry wrote: >>> On 12/10/14, 5:27 PM, Brian Stansberry wrote: >>>> On 12/10/14, 5:14 PM, Jason Greene wrote: >>>>>>> On 12/10/2014 10:30 AM, Brian Stansberry wrote: >>>>>>>> On 12/10/14, 10:06 AM, David M. Lloyd wrote: >>>>>>>>> On 12/10/2014 09:52 AM, Brian Stansberry wrote: >>>>>>>>>> On 12/10/14, 9:22 AM, Kabir Khan wrote: >>>>>>>>>>> Why not something along the lines of >>>>>>>>>>> :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})? >>>>>>>>>>> Internally that could create a composite for us, giving complex >>>>>>>>>>> attribute functionality while avoiding the messy resource >>>>>>>>>>> descriptions >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On the branch of the thread where I'm discussing with Tomaz, he >>>>>>>>>> raised >>>>>>>>>> the same idea, which I think is a good one. I think a >>>>>>>>>> "write-attributes" >>>>>>>>>> with no relationship to attribute-group makes more sense though. >>>>>>>>> >>>>>>>>> I agree. I have always felt that we should allow more than level of >>>>>>>>> grouping. >>>>>>>> >>>>>>>> Did you mean "should NOT allow"? >>>>>>> >>>>>>> No, I mean multiple levels _should_ be allowed, just with multiple >>>>>>> qualifiers. Multiple attribute writing per resource _should_ be >>>>>>> allowed >>>>>>> regardless of the depth or mixture of nesting. >>>>>>> >>>>>>> I.e. I should be able to do something like :write-attributes({"foo" = >>>>>>> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard >>>>>>> necessary to deal with attribute group navigation. >>>>>>> >>>>> >>>>> Hmm that nested syntax is an orthogonal feature IMO. I think that >>>>> requires a lot more thought, as its basically inventing another nested >>>>> dmr-path grammar. Not to say that we shouldn?t have that I just see >>>>> rabbit hole there. >>>>> >>>> >>>> Weird timing. I'm writing the JIRA for "write-attributes", trying to be >>>> precise, and I just now hit that rabbit hole. >>>> >>>> We already have the syntax, but it's used in the *value* of the "name" >>>> parameter to "write-attribute". Here we are using it in the parameter >>>> *name*. That makes it impractical to have a proper list of >>>> request-properties (aka params) in the read-operation-description output >>>> for the write-attributes op registered against a given address. Without >>>> that syntax, the parameter list would look much like the parameters for >>>> the resource's "add" operation. >>>> >>>> Further down the rabbit hole, thinking about this earlier I realized the >>>> read-operation-description output for the "write-attribute" operation is >>>> not as good as it could be. For any given resource, the description of >>>> the "name" parameter could/should include the legal values, i.e. the >>>> names of the writable attributes. We don't do that, and now we really >>>> can't. >>>> >>> >>> I gave up writing up the JIRA, as I want it to be precise and it can't >>> be precise enough until we have a good solution to this question. An >>> ugly one is: >>> >>> :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}]) >>> >>> That's a lot more confusing and verbose than >>> >>> :write-attributes(foo=123,bar.baz.zap=hello) >> >> I guess I missed a beat; why can't we do the latter? Is it because of >> the way we describe operations? IMO this operation should be on an >> equal footing with adding resources and we should have a uniform means >> to describe it as such. >> > > We describe the parameters to operations, including their names, and for > all cases up to now those are easily and statically known. The CLI > validates the parameter names used in low-level ops against the description. > > This can be solved by analyzing any complex attributes and outputing all > valid paths, using syntax like [] or [?] or [*] to indicate path > segments that represent elements in a list. We don't allow '.', '[' or > ']' in attribute/field names, so the presence of the [ is enough to > indicate that a list element is being described; the remaining ']', '?]' > or '*]' are just to improve readability. I prefer a simple '[]'. > IMHO my post ^^^ is wrong-headed. I don't think we should try and describe this kind of thing this way in the operation description. The CLI can't take an operation description listing legal values like bar[*].baz and use it the same way it can use plain old "bar". The string "bar[*].baz" is not valid input to send to the server; the user has to replace the * with a number. Since the CLI can't just use the string as is, there's not much benefit sending a bunch of text from the server. Fundamentally, the CLI needs to specially handle the parameter names for the "write-attributes" op, and the value for the "name" parameter for the "write-attribute" op: 1) There needs to be special tab completion behavior. For example, after the user types 'bar', if they hit tab, in the write-attributes case, the output is . = This reflects that the user can either provide a deeper path into the complex attribute, or move on to specifying the value of param "bar". In the write-attribute case, after the user types name=bar and hits tab, the output is: . , Comma instead of = to indicate they want to move on to the next param. Similar stuff for the [ and ] chars when dealing with lists. 2) Before sending a low-level op, the CLI validates the op's param names against the param names listed in the operation description. This validation should understand how to validate bar[0].baz. These two aspects of behavior could just be hard-coded into the CLI. To be formal though, we could add a couple pieces of boolean metadata to the parameter description: a) one indicating that the parameter name itself can be expanded into a deeper path. This would be used in the params to the "write-attributes" op. b) one indicating that the parameter value can be expanded from the formally specified legal values. This would be used with the "name" param for the "write-attribute" op, if we ever improved its description to properly list the legal values. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Fri Dec 12 03:14:38 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 12 Dec 2014 09:14:38 +0100 Subject: [wildfly-dev] A write-attributes op, and dealing with complex attribute paths In-Reply-To: <548A07F4.5000001@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> <5488D8AF.7090200@redhat.com> <5488D92F.8040903@redhat.com> <5488DF2B.6090800@redhat.com> <548A07F4.5000001@redhat.com> Message-ID: <04A6F3F7-E67F-4380-8061-BB475645C815@redhat.com> It?s hard to see the full context of this email thread, but here are two proposals I would like to comment on: a) write attribute groups / or writing to attribute groups? i.e :write-attribute-group(name=mygroup, value={attr1=a, attr2=b}) b) nested attribute syntax i.e. :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}]) I think these are two different concerns, hence I am going to respond separately: What?s the intention of proposal a)? Do you want to define new attribute groups this way or do you want to write values of attributes that belong to a specific group? I have similar problems with proposal b). What?s the intention behind the nested attribute syntax? A more convenient way to address complex attributes? Or does this address attributes that belong to child resources? From brian.stansberry at redhat.com Fri Dec 12 10:08:10 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 12 Dec 2014 09:08:10 -0600 Subject: [wildfly-dev] A write-attributes op, and dealing with complex attribute paths In-Reply-To: <04A6F3F7-E67F-4380-8061-BB475645C815@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> <5488D8AF.7090200@redhat.com> <5488D92F.8040903@redhat.com> <5488DF2B.6090800@redhat.com> <548A07F4.5000001@redhat.com> <04A6F3F7-E67F-4380-8061-BB475645C815@redhat.com> Message-ID: <548B04DA.5040303@redhat.com> On 12/12/14, 2:14 AM, Heiko Braun wrote: > > It?s hard to see the full context of this email thread, but here are two proposals I would like to comment on: > > a) write attribute groups / or writing to attribute groups? > i.e :write-attribute-group(name=mygroup, value={attr1=a, attr2=b}) > > b) nested attribute syntax > i.e. :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}]) > > > I think these are two different concerns, hence I am going to respond separately: > > What?s the intention of proposal a)? Do you want to define new attribute groups this way or do you want to write values of attributes that belong to a specific group? > I don't propose to do a). The current proposal is this: :write-attributes(attr1=5,attr2=true) No relationship at all to attribute groups. The idea for it just evolved from an earlier suggestion in the thread for a). This is simply a simpler syntax for a CLI batch that has two steps batch :write-attribute(name=attr1,value=5) :write-attribute(name=att2,value=true) run-batch The batch/run-batch is just CLI syntax for grouping in a "composite" op, so the console could take advantage of the same thing if it wishes, eliminating some composites. The "composite" op then is only needed if the steps involve > 1 address, or if some step is something other than write-attribute. > I have similar problems with proposal b). What?s the intention behind the nested attribute syntax? A more convenient way to address complex attributes? Yes, a more convenient way to address complex attributes. The current proposal is not your b) though. There are two uses for nested-attribute syntax: :write-attribute(name=bar[1].baz,value=true) :write-attributes(attr1=5,bar[1].baz=true) The latter is just syntactic sugar for a 2 step composite where the 2nd step is the former. Or does this address attributes that belong to child resources? No, not at all. The target of an operation is indicated by its address. > > > > > > > > > > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Mon Dec 15 03:24:59 2014 From: hbraun at redhat.com (Heiko Braun) Date: Mon, 15 Dec 2014 09:24:59 +0100 Subject: [wildfly-dev] A write-attributes op, and dealing with complex attribute paths In-Reply-To: <548B04DA.5040303@redhat.com> References: <548754D5.9090402@redhat.com> <54886C54.9070704@redhat.com> <54886F86.2020706@redhat.com> <5488752D.3050706@redhat.com> <5488868B.9070306@redhat.com> <5488885F.5030103@redhat.com> <01184A30-596F-4544-98F8-A2326E2C4132@redhat.com> <5488D6CA.9020903@redhat.com> <5488D8AF.7090200@redhat.com> <5488D92F.8040903@redhat.com> <5488DF2B.6090800@redhat.com> <548A07F4.5000001@redhat.com> <04A6F3F7-E67F-4380-8061-BB475645C815@redhat.com> <548B04DA.5040303@redhat.com> Message-ID: Thanks for the clarification Brian. > On 12 Dec 2014, at 16:08, Brian Stansberry wrote: > > On 12/12/14, 2:14 AM, Heiko Braun wrote: >> >> It?s hard to see the full context of this email thread, but here are two proposals I would like to comment on: >> >> a) write attribute groups / or writing to attribute groups? >> i.e :write-attribute-group(name=mygroup, value={attr1=a, attr2=b}) >> >> b) nested attribute syntax >> i.e. :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}]) >> >> >> I think these are two different concerns, hence I am going to respond separately: >> >> What?s the intention of proposal a)? Do you want to define new attribute groups this way or do you want to write values of attributes that belong to a specific group? >> > > I don't propose to do a). The current proposal is this: > > :write-attributes(attr1=5,attr2=true) > > No relationship at all to attribute groups. The idea for it just evolved from an earlier suggestion in the thread for a). > > This is simply a simpler syntax for a CLI batch that has two steps > > batch > :write-attribute(name=attr1,value=5) > :write-attribute(name=att2,value=true) > run-batch > > The batch/run-batch is just CLI syntax for grouping in a "composite" op, so the console could take advantage of the same thing if it wishes, eliminating some composites. The "composite" op then is only needed if the steps involve > 1 address, or if some step is something other than write-attribute. > >> I have similar problems with proposal b). What?s the intention behind the nested attribute syntax? A more convenient way to address complex attributes? > > Yes, a more convenient way to address complex attributes. > > The current proposal is not your b) though. There are two uses for nested-attribute syntax: > > :write-attribute(name=bar[1].baz,value=true) > > :write-attributes(attr1=5,bar[1].baz=true) > > The latter is just syntactic sugar for a 2 step composite where the 2nd step is the former. > > Or does this address attributes that belong to child resources? > > No, not at all. The target of an operation is indicated by its address. > >> >> >> >> >> >> >> >> >> >> >> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141215/184a5ca8/attachment-0001.html From smarlow at redhat.com Mon Dec 15 15:44:20 2014 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 15 Dec 2014 15:44:20 -0500 Subject: [wildfly-dev] the WildFly 9 org.jboss.metadata.common module is missing javax.persistence... Message-ID: <548F4824.3020005@redhat.com> Some of the WildFly 9 TCK tests are failing because javax.persistence.api is missing from the org.jboss.metadata.common module. In WildFly 8.2, we had [1] org.jboss.metadata which had various javax APIs. In WildFly 9, org.jboss.metadata.ejb has the different javax APIs but org.jboss.metadata.common [2] does not. How should this be fixed? Scott [1] https://github.com/wildfly/wildfly/blob/8.x/build/src/main/resources/modules/system/layers/base/org/jboss/metadata/main/module.xml [2] dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules/system/layers/base/org/jboss/metadata/common/main/module.xml From stuart.w.douglas at gmail.com Mon Dec 15 15:46:14 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 16 Dec 2014 07:46:14 +1100 Subject: [wildfly-dev] the WildFly 9 org.jboss.metadata.common module is missing javax.persistence... In-Reply-To: <548F4824.3020005@redhat.com> References: <548F4824.3020005@redhat.com> Message-ID: <548F4896.5000008@gmail.com> By adding the imports? Stuart Scott Marlow wrote: > Some of the WildFly 9 TCK tests are failing because > javax.persistence.api is missing from the org.jboss.metadata.common > module. In WildFly 8.2, we had [1] org.jboss.metadata which had various > javax APIs. In WildFly 9, org.jboss.metadata.ejb has the different > javax APIs but org.jboss.metadata.common [2] does not. > > How should this be fixed? > > Scott > > [1] > https://github.com/wildfly/wildfly/blob/8.x/build/src/main/resources/modules/system/layers/base/org/jboss/metadata/main/module.xml > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [2] > dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules/system/layers/base/org/jboss/metadata/common/main/module.xml > > > > > > > > > > > > > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Mon Dec 15 16:09:02 2014 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 15 Dec 2014 16:09:02 -0500 Subject: [wildfly-dev] the WildFly 9 org.jboss.metadata.common module is missing javax.persistence... In-Reply-To: <548F4896.5000008@gmail.com> References: <548F4824.3020005@redhat.com> <548F4896.5000008@gmail.com> Message-ID: <548F4DEE.2090807@redhat.com> On 12/15/2014 03:46 PM, Stuart Douglas wrote: > By adding the imports? The current location for the module definition appears to be web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/common/main/module.xml, is that the right location for org.jboss.metadata.common? > > Stuart > > Scott Marlow wrote: >> Some of the WildFly 9 TCK tests are failing because >> javax.persistence.api is missing from the org.jboss.metadata.common >> module. In WildFly 8.2, we had [1] org.jboss.metadata which had various >> javax APIs. In WildFly 9, org.jboss.metadata.ejb has the different >> javax APIs but org.jboss.metadata.common [2] does not. >> >> How should this be fixed? >> >> Scott >> >> [1] >> https://github.com/wildfly/wildfly/blob/8.x/build/src/main/resources/modules/system/layers/base/org/jboss/metadata/main/module.xml >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> [2] >> dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules/system/layers/base/org/jboss/metadata/common/main/module.xml >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From stuart.w.douglas at gmail.com Mon Dec 15 16:29:56 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 16 Dec 2014 08:29:56 +1100 Subject: [wildfly-dev] the WildFly 9 org.jboss.metadata.common module is missing javax.persistence... In-Reply-To: <548F4DEE.2090807@redhat.com> References: <548F4824.3020005@redhat.com> <548F4896.5000008@gmail.com> <548F4DEE.2090807@redhat.com> Message-ID: <548F52D4.4070302@gmail.com> Yes Stuart Scott Marlow wrote: > On 12/15/2014 03:46 PM, Stuart Douglas wrote: >> By adding the imports? > > The current location for the module definition appears to be > web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/common/main/module.xml, > is that the right location for org.jboss.metadata.common? > > >> >> Stuart >> >> Scott Marlow wrote: >>> Some of the WildFly 9 TCK tests are failing because >>> javax.persistence.api is missing from the org.jboss.metadata.common >>> module. In WildFly 8.2, we had [1] org.jboss.metadata which had various >>> javax APIs. In WildFly 9, org.jboss.metadata.ejb has the different >>> javax APIs but org.jboss.metadata.common [2] does not. >>> >>> How should this be fixed? >>> >>> Scott >>> >>> [1] >>> https://github.com/wildfly/wildfly/blob/8.x/build/src/main/resources/modules/system/layers/base/org/jboss/metadata/main/module.xml >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [2] >>> dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules/system/layers/base/org/jboss/metadata/common/main/module.xml >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Mon Dec 15 19:15:33 2014 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 15 Dec 2014 19:15:33 -0500 Subject: [wildfly-dev] the WildFly 9 org.jboss.metadata.common module is missing javax.persistence... In-Reply-To: <548F52D4.4070302@gmail.com> References: <548F4824.3020005@redhat.com> <548F4896.5000008@gmail.com> <548F4DEE.2090807@redhat.com> <548F52D4.4070302@gmail.com> Message-ID: <548F79A5.8000505@redhat.com> I tried adding javax.persistence.api to org.jboss.metadata.common [3] but get the following build error [4]. ERROR] Failed to execute goal org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1.0.0.Alpha6:build (feature-pack-build) on project wildfly-web-feature-pack: Execution feature-pack-build of goal org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1.0.0.Alpha6:build failed: java.lang.RuntimeException: Some errors were encountered creating the feature pack [ERROR] Missing module ModuleIdentifier{name='javax.persistence.api', slot='main'}. Module was required by [ModuleIdentifier{name='org.jboss.metadata.common', slot='main'}] [ERROR] Is there another file besides web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/common/main/module.xml that also needs the dependency? Scott [3] https://github.com/scottmarlow/wildfly/tree/jbossmetadata_javaxpersistence [4] https://gist.github.com/scottmarlow/7d04490677e93a7de35f On 12/15/2014 04:29 PM, Stuart Douglas wrote: > Yes > > Stuart > > Scott Marlow wrote: >> On 12/15/2014 03:46 PM, Stuart Douglas wrote: >>> By adding the imports? >> >> The current location for the module definition appears to be >> web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/common/main/module.xml, >> >> is that the right location for org.jboss.metadata.common? >> >> >>> >>> Stuart >>> >>> Scott Marlow wrote: >>>> Some of the WildFly 9 TCK tests are failing because >>>> javax.persistence.api is missing from the org.jboss.metadata.common >>>> module. In WildFly 8.2, we had [1] org.jboss.metadata which had various >>>> javax APIs. In WildFly 9, org.jboss.metadata.ejb has the different >>>> javax APIs but org.jboss.metadata.common [2] does not. >>>> >>>> How should this be fixed? >>>> >>>> Scott >>>> >>>> [1] >>>> https://github.com/wildfly/wildfly/blob/8.x/build/src/main/resources/modules/system/layers/base/org/jboss/metadata/main/module.xml >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [2] >>>> dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules/system/layers/base/org/jboss/metadata/common/main/module.xml >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Mon Dec 15 21:59:29 2014 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 15 Dec 2014 21:59:29 -0500 Subject: [wildfly-dev] the WildFly 9 org.jboss.metadata.common module is missing javax.persistence... In-Reply-To: <548F79A5.8000505@redhat.com> References: <548F4824.3020005@redhat.com> <548F4896.5000008@gmail.com> <548F4DEE.2090807@redhat.com> <548F52D4.4070302@gmail.com> <548F79A5.8000505@redhat.com> Message-ID: <548FA011.60703@redhat.com> The build succeeds if we specify 'optional="true"' (https://github.com/wildfly/wildfly-build-tools/blob/master/feature-pack-build-maven-plugin/src/main/java/org/wildfly/build/featurepack/FeaturePackBuilder.java does not do the same verification for optional dependencies). On 12/15/2014 07:15 PM, Scott Marlow wrote: > I tried adding javax.persistence.api to org.jboss.metadata.common [3] > but get the following build error [4]. > > ERROR] Failed to execute goal > org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1.0.0.Alpha6:build > (feature-pack-build) on project wildfly-web-feature-pack: Execution > feature-pack-build of goal > org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1.0.0.Alpha6:build > failed: java.lang.RuntimeException: Some errors were encountered > creating the feature pack > [ERROR] Missing module ModuleIdentifier{name='javax.persistence.api', > slot='main'}. Module was required by > [ModuleIdentifier{name='org.jboss.metadata.common', slot='main'}] > [ERROR] > > Is there another file besides > web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/common/main/module.xml > that also needs the dependency? > > Scott > > [3] > https://github.com/scottmarlow/wildfly/tree/jbossmetadata_javaxpersistence > > [4] https://gist.github.com/scottmarlow/7d04490677e93a7de35f > > On 12/15/2014 04:29 PM, Stuart Douglas wrote: >> Yes >> >> Stuart >> >> Scott Marlow wrote: >>> On 12/15/2014 03:46 PM, Stuart Douglas wrote: >>>> By adding the imports? >>> >>> The current location for the module definition appears to be >>> web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/common/main/module.xml, >>> >>> is that the right location for org.jboss.metadata.common? >>> >>> >>>> >>>> Stuart >>>> >>>> Scott Marlow wrote: >>>>> Some of the WildFly 9 TCK tests are failing because >>>>> javax.persistence.api is missing from the org.jboss.metadata.common >>>>> module. In WildFly 8.2, we had [1] org.jboss.metadata which had various >>>>> javax APIs. In WildFly 9, org.jboss.metadata.ejb has the different >>>>> javax APIs but org.jboss.metadata.common [2] does not. >>>>> >>>>> How should this be fixed? >>>>> >>>>> Scott >>>>> >>>>> [1] >>>>> https://github.com/wildfly/wildfly/blob/8.x/build/src/main/resources/modules/system/layers/base/org/jboss/metadata/main/module.xml >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [2] >>>>> dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules/system/layers/base/org/jboss/metadata/common/main/module.xml >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 stuart.w.douglas at gmail.com Tue Dec 16 00:00:44 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 16 Dec 2014 05:00:44 +0000 Subject: [wildfly-dev] the WildFly 9 org.jboss.metadata.common module is missing javax.persistence... References: <548F4824.3020005@redhat.com> <548F4896.5000008@gmail.com> <548F4DEE.2090807@redhat.com> <548F52D4.4070302@gmail.com> <548F79A5.8000505@redhat.com> Message-ID: It looks like this is only used for a single enum. I will remove it in jboss metadata, and use our own version of the enum instead. Stuart On Tue Dec 16 2014 at 11:15:48 AM Scott Marlow wrote: > I tried adding javax.persistence.api to org.jboss.metadata.common [3] > but get the following build error [4]. > > ERROR] Failed to execute goal > org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1. > 0.0.Alpha6:build > (feature-pack-build) on project wildfly-web-feature-pack: Execution > feature-pack-build of goal > org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1. > 0.0.Alpha6:build > failed: java.lang.RuntimeException: Some errors were encountered > creating the feature pack > [ERROR] Missing module ModuleIdentifier{name='javax.persistence.api', > slot='main'}. Module was required by > [ModuleIdentifier{name='org.jboss.metadata.common', slot='main'}] > [ERROR] > > Is there another file besides > web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ > metadata/common/main/module.xml > that also needs the dependency? > > Scott > > [3] > https://github.com/scottmarlow/wildfly/tree/jbossmetadata_javaxpersistence > > [4] https://gist.github.com/scottmarlow/7d04490677e93a7de35f > > On 12/15/2014 04:29 PM, Stuart Douglas wrote: > > Yes > > > > Stuart > > > > Scott Marlow wrote: > >> On 12/15/2014 03:46 PM, Stuart Douglas wrote: > >>> By adding the imports? > >> > >> The current location for the module definition appears to be > >> web-feature-pack/src/main/resources/modules/system/layers/ > base/org/jboss/metadata/common/main/module.xml, > >> > >> is that the right location for org.jboss.metadata.common? > >> > >> > >>> > >>> Stuart > >>> > >>> Scott Marlow wrote: > >>>> Some of the WildFly 9 TCK tests are failing because > >>>> javax.persistence.api is missing from the org.jboss.metadata.common > >>>> module. In WildFly 8.2, we had [1] org.jboss.metadata which had > various > >>>> javax APIs. In WildFly 9, org.jboss.metadata.ejb has the different > >>>> javax APIs but org.jboss.metadata.common [2] does not. > >>>> > >>>> How should this be fixed? > >>>> > >>>> Scott > >>>> > >>>> [1] > >>>> https://github.com/wildfly/wildfly/blob/8.x/build/src/main/ > resources/modules/system/layers/base/org/jboss/metadata/main/module.xml > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> [2] > >>>> dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules/system/ > layers/base/org/jboss/metadata/common/main/module.xml > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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/20141216/a5bd5ebd/attachment-0001.html From stuart.w.douglas at gmail.com Tue Dec 16 00:32:59 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 16 Dec 2014 05:32:59 +0000 Subject: [wildfly-dev] the WildFly 9 org.jboss.metadata.common module is missing javax.persistence... References: <548F4824.3020005@redhat.com> <548F4896.5000008@gmail.com> <548F4DEE.2090807@redhat.com> <548F52D4.4070302@gmail.com> <548F79A5.8000505@redhat.com> Message-ID: This should fix it: https://github.com/wildfly/wildfly/pull/7043 On Tue Dec 16 2014 at 4:00:44 PM Stuart Douglas wrote: > It looks like this is only used for a single enum. I will remove it in > jboss metadata, and use our own version of the enum instead. > > Stuart > > > > > On Tue Dec 16 2014 at 11:15:48 AM Scott Marlow wrote: > >> I tried adding javax.persistence.api to org.jboss.metadata.common [3] >> but get the following build error [4]. >> >> ERROR] Failed to execute goal >> org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1. >> 0.0.Alpha6:build >> (feature-pack-build) on project wildfly-web-feature-pack: Execution >> feature-pack-build of goal >> org.wildfly.build:wildfly-feature-pack-build-maven-plugin:1. >> 0.0.Alpha6:build >> failed: java.lang.RuntimeException: Some errors were encountered >> creating the feature pack >> [ERROR] Missing module ModuleIdentifier{name='javax.persistence.api', >> slot='main'}. Module was required by >> [ModuleIdentifier{name='org.jboss.metadata.common', slot='main'}] >> [ERROR] >> >> Is there another file besides >> web-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ >> metadata/common/main/module.xml >> that also needs the dependency? >> >> Scott >> >> [3] >> https://github.com/scottmarlow/wildfly/tree/jbossmetadata_ja >> vaxpersistence >> >> [4] https://gist.github.com/scottmarlow/7d04490677e93a7de35f >> >> On 12/15/2014 04:29 PM, Stuart Douglas wrote: >> > Yes >> > >> > Stuart >> > >> > Scott Marlow wrote: >> >> On 12/15/2014 03:46 PM, Stuart Douglas wrote: >> >>> By adding the imports? >> >> >> >> The current location for the module definition appears to be >> >> web-feature-pack/src/main/resources/modules/system/layers/ba >> se/org/jboss/metadata/common/main/module.xml, >> >> >> >> is that the right location for org.jboss.metadata.common? >> >> >> >> >> >>> >> >>> Stuart >> >>> >> >>> Scott Marlow wrote: >> >>>> Some of the WildFly 9 TCK tests are failing because >> >>>> javax.persistence.api is missing from the org.jboss.metadata.common >> >>>> module. In WildFly 8.2, we had [1] org.jboss.metadata which had >> various >> >>>> javax APIs. In WildFly 9, org.jboss.metadata.ejb has the different >> >>>> javax APIs but org.jboss.metadata.common [2] does not. >> >>>> >> >>>> How should this be fixed? >> >>>> >> >>>> Scott >> >>>> >> >>>> [1] >> >>>> https://github.com/wildfly/wildfly/blob/8.x/build/src/main/r >> esources/modules/system/layers/base/org/jboss/metadata/main/module.xml >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> [2] >> >>>> dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/modules/system/lay >> ers/base/org/jboss/metadata/common/main/module.xml >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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/20141216/5ebb131d/attachment.html From rory.odonnell at oracle.com Tue Dec 16 07:29:39 2014 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 16 Dec 2014 12:29:39 +0000 Subject: [wildfly-dev] Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net Message-ID: <549025B3.1090007@oracle.com> Hi Jason/Tomaz, Now that JDK 9 Early Access build images are modular [1], there is a fresh Early Access build for JDK 9 b42 available on java.net. The summary of changes are listed here In addition, there are new Early Access builds for the ongoing update releases. The Early Access build for JDK 8u40 b18 is available on java.net, with the summary of changes listed here. Finally, the Early Access build for JDK 7u80 b03 is available on java.net, with the summary of changes listed here. As we enter the later phases of development for JDK 7u80 & JDK 8u40, please log any show stoppers as soon as possible. Rgds,Rory [1] http://mreinhold.org/blog/jigsaw-modular-images -- 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/20141216/a7b4e125/attachment.html From wfink at redhat.com Tue Dec 16 11:20:18 2014 From: wfink at redhat.com (Wolf-Dieter Fink) Date: Tue, 16 Dec 2014 17:20:18 +0100 Subject: [wildfly-dev] bind the server against all interfaces "-b 0.0.0.0" or configuration Message-ID: <54905BC2.3070608@redhat.com> To use EJB invocations from localhost and remote with IP I try to bind the server instances against all interfaces with -b 0.0.0.0 or changing the public-interface configuration to . The client connect the real IP. I use the ejb-remote quickstart to reproduce. If I use the standalone.xml profile it works fine. But change to -ha.xml will fail. Do I need to use a different configuration to being able to use all interfaces? From my point of view this is a bug as I can't configure the server for all interfaces! The ejb-remote server side is changed, the jboss-ejb3.xml mark the beans as Clustered! If the server starts - with 0.0.0.0 or any-address - JGroups will not start correct: 17:14:19,522 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-13) MSC000001: Failed to start service jboss.jgroups.channel.ee: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.net.BindException: [UDP] /0.0.0.0 is not a valid address on any local network interface at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:93) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.security.PrivilegedActionException: java.net.BindException: [UDP] /0.0.0.0 is not a valid address on any local network interface at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:638) at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87) at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:90) ... 5 more Caused by: java.net.BindException: [UDP] /0.0.0.0 is not a valid address on any local network interface at org.jgroups.util.Util.checkIfValidAddress(Util.java:3458) at org.jgroups.stack.Configurator.ensureValidBindAddresses(Configurator.java:902) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:118) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477) at org.jgroups.JChannel.init(JChannel.java:848) at org.jgroups.JChannel.(JChannel.java:159) at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:84) at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:81) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:634) ... 7 more ================================ If the server start with "-b MY-IP" and the default standalone-ha.xml, it works with the following message and the cluster-connections seems not correct established INFO: Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='redhat', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='${jboss.node.name}', destinationPort=8080}], resolvedDestination=[Destination address=${jboss.node.name}, destination port=8080]} in cluster ejb java.lang.RuntimeException: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?# at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79) at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405) at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?# at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:102) at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79) at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405) at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ...asynchronous invocation...(Unknown Source) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) ... 8 more Caused by: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?# at java.net.URI$Parser.fail(URI.java:2829) at java.net.URI$Parser.parseAuthority(URI.java:3167) at java.net.URI$Parser.parseHierarchical(URI.java:3078) at java.net.URI$Parser.parse(URI.java:3034) at java.net.URI.(URI.java:680) at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:100) at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298) ... 12 more From tomaz.cerar at gmail.com Tue Dec 16 15:58:15 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 16 Dec 2014 21:58:15 +0100 Subject: [wildfly-dev] bind the server against all interfaces "-b 0.0.0.0" or configuration In-Reply-To: <54905BC2.3070608@redhat.com> References: <54905BC2.3070608@redhat.com> Message-ID: On Tue, Dec 16, 2014 at 5:20 PM, Wolf-Dieter Fink wrote: > > java.net.BindException: [UDP] /0.0.0.0 is not a valid address on any > local network interface > Mac OSX? if so that is known mac os/jdk limitation. The url stuff looks like a bug, non resolved expression is passed over. Can you create jira for that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141216/3406d1ee/attachment-0001.html From tomaz.cerar at gmail.com Tue Dec 16 17:20:00 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 16 Dec 2014 23:20:00 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net In-Reply-To: <549025B3.1090007@oracle.com> References: <549025B3.1090007@oracle.com> Message-ID: Rory, Looks like there is compiler regression in b42, that prevented wildfly-core from compiling Looks like that sub class doesn't import subclasses from interface that parent class implements. What is even more odd is that i can only reproduce this on few environments. Fix was simple https://github.com/ctomc/wildfly-core/commit/d29316a0c73fe74e587f4a8160a82e5933db919a but this should probably be fixed given that it worked in JDK 6, 7 & 8 I can try to prepare simple case to reproduce if you guys think this is worth exploring. After fix applied above, wildfly-core build & passes testsuite without any failures, http://teamcity.cafe-babe.org/viewLog.html?buildTypeId=WildFly_WildflyCore_Build&buildId=17035 -- tomaz On Tue, Dec 16, 2014 at 1:29 PM, Rory O'Donnell wrote: > > Hi Jason/Tomaz, > > Now that JDK 9 Early Access build images are modular [1], there is a fresh > Early Access build for JDK 9 b42 > available on java.net. The summary of > changes are listed here > > > In addition, there are new Early Access builds for the ongoing update > releases. > > The Early Access build for JDK 8u40 b18 > is available on java.net, with the > summary of changes listed here. > > > Finally, the Early Access build for JDK 7u80 b03 > is available on java.net, > with the summary of changes listed here. > > > As we enter the later phases of development for JDK 7u80 & JDK 8u40, > please log any show stoppers as soon as possible. > > Rgds,Rory > > [1] http://mreinhold.org/blog/jigsaw-modular-images > > -- > 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/20141216/debd29ec/attachment.html From rory.odonnell at oracle.com Tue Dec 16 18:33:58 2014 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 16 Dec 2014 23:33:58 +0000 Subject: [wildfly-dev] Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net In-Reply-To: References: <549025B3.1090007@oracle.com> Message-ID: <5490C166.8040603@oracle.com> On 16/12/2014 22:20, Toma? Cerar wrote: > Rory, > > Looks like there is compiler regression in b42, that prevented > wildfly-core from compiling > > Looks like that sub class doesn't import subclasses from interface > that parent class implements. > What is even more odd is that i can only reproduce this on few > environments. > Fix was simple > https://github.com/ctomc/wildfly-core/commit/d29316a0c73fe74e587f4a8160a82e5933db919a > but this should probably be fixed given that it worked in JDK 6, 7 & 8 > > I can try to prepare simple case to reproduce if you guys think this > is worth exploring. Yes please Tomaz, could you log a bug at bugs.sun.com ? Once you have a Java Incident, send it to us and we will move it forward. Rgds,Rory > > After fix applied above, wildfly-core build & passes testsuite without > any failures, > http://teamcity.cafe-babe.org/viewLog.html?buildTypeId=WildFly_WildflyCore_Build&buildId=17035 > > > -- > tomaz > > > On Tue, Dec 16, 2014 at 1:29 PM, Rory O'Donnell > > wrote: > > Hi Jason/Tomaz, > > Now that JDK 9 Early Access build images are modular [1], there is > a fresh > Early Access build for JDK 9 b42 > available on java.net . The summary of > changes are listed here > > > In addition, there are new Early Access builds for the ongoing > update releases. > > The Early Access build for JDK 8u40 b18 > is available on java.net > , with the > summary of changes listed here. > > > Finally, the Early Access build for JDK 7u80 b03 > is available on java.net > , > with the summary of changes listed here. > > > As we enter the later phases of development for JDK 7u80 & JDK 8u40, > please log any show stoppers as soon as possible. > > Rgds,Rory > > [1] http://mreinhold.org/blog/jigsaw-modular-images > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > -- 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/20141216/e4ae1ff1/attachment.html From tdiesler at redhat.com Wed Dec 17 04:28:45 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Wed, 17 Dec 2014 10:28:45 +0100 Subject: [wildfly-dev] WildFly domain on OpenShift Origin In-Reply-To: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> Message-ID: <44C922B6-FD83-44DF-9DC5-87D7AED804DA@redhat.com> Folks, following up on this topic, I worked a little more on WildFly-Camel in Kubernetes/OpenShift. These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015) WildFly-Camel on Docker WildFly-Camel on OpenShift The setup looks like this We can now manage these individual wildfly nodes. The domain controller (DC) is replicated once, the host definition is replicated three times. Theoretically, this means that there is no single point of failure with the domain controller any more - kube would respawn the DC on failure Here some ideas for improvement ? In a kube env we should be able to swap out containers based on some criteria. It should be possible to define these criteria, emit events based on them create/remove/replace containers automatically. Additionally a human should be able to make qualified decisions through a console and create/remove/replace containers easily. Much of the needed information is in jmx. Heiko told me that there is a project that can push events to influx db - something to look at. If information display contained in jmx in a console has value (e.g in hawtio) that information must be aggregated and visible for each node. Currently, we have a round robin service on 8080 which would show a different hawtio instance on every request - this is nonsense. I can see a number of high level items: #1 a thing that aggregates jmx content - possibly multiple MBeanServers in the DC VM that delegate to respective MBeanServers on other hosts, so that a management client can pickup the info from one service #2 look at the existing inluxdb thing and research into how to automate the replacement of containers #3 from the usability perspective, there may need to be an openshift profile in the console(s) because some operations may not make sense in that env cheers ?thomas PS: looking forward to an exiting ride in 2015 > On 5 Dec 2014, at 14:36, Thomas Diesler wrote: > > Folks, > > I?ve recently been looking at WildFly container deployments on OpenShift V3. The following setup is documented here > > > > The example architecture consists of a set of three high available (HA) servers running REST endpoints. > For server replication and failover we use Kubernetes. Each server runs in a dedicated Pod that we access via Services. > > This approach comes with a number of benefits, which are sufficiently explained in various OpenShift , Kubernetes and Docker materials, but also with a number of challenges. Lets look at those in more detail ? > > In the example above Kubernetes replicates a number of standalone containers and isolates them in a Pod each with limited access from the outside world. > > * The management interfaces are not accessible > * The management consoles are not visible > > With WildFly-Camel we have a Hawt.io console that allows us to manage Camel Routes configured or deployed to the WildFly runtime. > The WildFly console manages aspects of the appserver. > > In a more general sense, I was wondering how the WildFly domain model maps to the Kubernetes runtime environment and how these server instances are managed and information about them relayed back to the sysadmin > > a) Should these individual wildfly instances somehow be connected to each other (i.e. notion of domain)? > b) How would an HA singleton service work? > c) What level of management should be exposed to the outside? > d) Should it be possible to modify runtime behaviour of these servers (i.e. write access to config)? > e) Should deployment be supported at all? > f) How can a server be detected that has gone bad? > g) Should logs be aggregated? > h) Should there be a common management view (i.e. console) for these servers? > i) etc ? > > Are these concerns already being addressed for WildFly? > > Is there perhaps even an already existing design that I could look at? > > Can such an effort be connected to the work that is going on in Fabric8? > > cheers > ?thomas > > PS: it would be area that we @ wildfly-camel were interested to work on > > _______________________________________________ > 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/20141217/50297169/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.tiff Type: image/tiff Size: 48688 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141217/50297169/attachment-0001.tiff -------------- next part -------------- A non-text attachment was scrubbed... Name: Foto.JPG Type: image/jpeg Size: 70432 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141217/50297169/attachment-0001.jpe From tdiesler at redhat.com Wed Dec 17 05:20:28 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Wed, 17 Dec 2014 11:20:28 +0100 Subject: [wildfly-dev] WildFly domain on OpenShift Origin In-Reply-To: <54914E5C.6040409@redhat.com> References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> <44C922B6-FD83-44DF-9DC5-87D7AED804DA@redhat.com> <54914E5C.6040409@redhat.com> Message-ID: <4B68A940-2754-4A2B-BCF4-D559807038B1@redhat.com> /reducing the cc noise Yes, I was hoping to hear that this has already been thought about. Is there a design document for this JMX aggregation? What are the possible target environments and functional requirements? Would this be reusable in a plain WildFly domain? cheers ?thomas > On 17 Dec 2014, at 10:35, Rob Davies wrote: > > Hi Thomas, > > it would be great to see this as an example quickstart in fabric8 - then you could pick up the jmx aggregation etc for free :) > >> Thomas Diesler 17 December 2014 09:28 >> Folks, >> >> following up on this topic, I worked a little more on WildFly-Camel in Kubernetes/OpenShift. >> >> These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015) >> >> WildFly-Camel on Docker >> WildFly-Camel on OpenShift >> >> The setup looks like this >> >> >> >> We can now manage these individual wildfly nodes. The domain controller (DC) is replicated once, the host definition is replicated three times. >> Theoretically, this means that there is no single point of failure with the domain controller any more - kube would respawn the DC on failure >> >> Here some ideas for improvement ? >> >> In a kube env we should be able to swap out containers based on some criteria. It should be possible to define these criteria, emit events based on them create/remove/replace containers automatically. >> Additionally a human should be able to make qualified decisions through a console and create/remove/replace containers easily. >> Much of the needed information is in jmx. Heiko told me that there is a project that can push events to influx db - something to look at. >> >> If information display contained in jmx in a console has value (e.g in hawtio) that information must be aggregated and visible for each node. >> Currently, we have a round robin service on 8080 which would show a different hawtio instance on every request - this is nonsense. >> >> I can see a number of high level items: >> >> #1 a thing that aggregates jmx content - possibly multiple MBeanServers in the DC VM that delegate to respective MBeanServers on other hosts, so that a management client can pickup the info from one service >> #2 look at the existing inluxdb thing and research into how to automate the replacement of containers >> #3 from the usability perspective, there may need to be an openshift profile in the console(s) because some operations may not make sense in that env >> >> cheers >> ?thomas >> >> PS: looking forward to an exiting ride in 2015 >> >> >> >> >> Thomas Diesler 5 December 2014 13:36 >> Folks, >> >> I?ve recently been looking at WildFly container deployments on OpenShift V3. The following setup is documented here >> >> This approach comes with a number of benefits, which are sufficiently explained in various OpenShift , Kubernetes and Docker materials, but also with a number of challenges. Lets look at those in more detail ? >> >> In the example above Kubernetes replicates a number of standalone containers and isolates them in a Pod each with limited access from the outside world. >> >> * The management interfaces are not accessible >> * The management consoles are not visible >> >> With WildFly-Camel we have a Hawt.io console that allows us to manage Camel Routes configured or deployed to the WildFly runtime. >> The WildFly console manages aspects of the appserver. >> >> In a more general sense, I was wondering how the WildFly domain model maps to the Kubernetes runtime environment and how these server instances are managed and information about them relayed back to the sysadmin >> >> a) Should these individual wildfly instances somehow be connected to each other (i.e. notion of domain)? >> b) How would an HA singleton service work? >> c) What level of management should be exposed to the outside? >> d) Should it be possible to modify runtime behaviour of these servers (i.e. write access to config)? >> e) Should deployment be supported at all? >> f) How can a server be detected that has gone bad? >> g) Should logs be aggregated? >> h) Should there be a common management view (i.e. console) for these servers? >> i) etc ? >> >> Are these concerns already being addressed for WildFly? >> >> Is there perhaps even an already existing design that I could look at? >> >> Can such an effort be connected to the work that is going on in Fabric8? >> >> cheers >> ?thomas >> >> PS: it would be area that we @ wildfly-camel were interested to work on >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141217/4314ca7f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141217/4314ca7f/attachment.jpg From brian.stansberry at redhat.com Wed Dec 17 09:42:18 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 17 Dec 2014 08:42:18 -0600 Subject: [wildfly-dev] WildFly domain on OpenShift Origin In-Reply-To: <44C922B6-FD83-44DF-9DC5-87D7AED804DA@redhat.com> References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> <44C922B6-FD83-44DF-9DC5-87D7AED804DA@redhat.com> Message-ID: <5491964A.3040306@redhat.com> On 12/17/14, 3:28 AM, Thomas Diesler wrote: > Folks, > > following up on this topic, I worked a little more on WildFly-Camel in > Kubernetes/OpenShift. > > These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015) > > * WildFly-Camel on Docker > > * WildFly-Camel on OpenShift > > Great. :) > > The setup looks like this > > > We can now manage these individual wildfly nodes. The domain controller > (DC) is replicated once, the host definition is replicated three times. > Theoretically, this means that there is no single point of failure with > the domain controller any more - kube would respawn the DC on failure > I'm heading on PTO tomorrow so likely won't be able to follow up on this question for a while, but one concern I had with the Kubernetes respawn approach was retaining any changes that had been made to the domain configuration. Unless the domain.xml comes from / is written to some shared storage available to the respawned DC, any changes made will be lost. Of course, if the DC is only being used for reads, this isn't an issue. > Here some ideas for improvement ? > > In a kube env we should be able to swap out containers based on some > criteria. It should be possible to define these criteria, emit events > based on them create/remove/replace containers automatically. > Additionally a human should be able to make qualified decisions through > a console and create/remove/replace containers easily. > Much of the needed information is in jmx. Heiko told me that there is a > project that can push events to influx db - something to look at. > > If information display contained in jmx in a console has value (e.g in > hawtio) that information must be aggregated and visible for each node. > Currently, we have a round robin service on 8080 which would show a > different hawtio instance on every request - this is nonsense. > > I can see a number of high level items: > > #1 a thing that aggregates jmx content - possibly multiple MBeanServers > in the DC VM that delegate to respective MBeanServers on other hosts, so > that a management client can pickup the info from one service > #2 look at the existing inluxdb thing and research into how to automate > the replacement of containers > #3 from the usability perspective, there may need to be an openshift > profile in the console(s) because some operations may not make sense in > that env > > cheers > ?thomas > > PS: looking forward to an exiting ride in 2015 > > >> On 5 Dec 2014, at 14:36, Thomas Diesler > > wrote: >> >> Folks, >> >> I?ve recently been looking at WildFly container deployments on >> OpenShift V3. The following setup is documented here >> >> >> >> >> The example architecture consists of a set of three high available >> (HA) servers running REST endpoints. >> For server replication and failover we use Kubernetes. Each server >> runs in a dedicated Pod that we access via Services. >> >> This approach comes with a number of benefits, which are sufficiently >> explained in various OpenShift >> , >> Kubernetes >> and >> Docker materials, but also with a number of >> challenges. Lets look at those in more detail ? >> >> In the example above Kubernetes replicates a number of standalone >> containers and isolates them in a Pod each with limited access from >> the outside world. >> >> * The management interfaces are not accessible >> * The management consoles are not visible >> >> With WildFly-Camel we have a Hawt.io >> console >> that allows us to manage Camel Routes configured or deployed to the >> WildFly runtime. >> The WildFly console manages aspects of the appserver. >> >> In a more general sense, I was wondering how the WildFly domain model >> maps to the Kubernetes runtime environment and how these server >> instances are managed and information about them relayed back to the >> sysadmin >> >> a) Should these individual wildfly instances somehow be connected to >> each other (i.e. notion of domain)? >> b) How would an HA singleton service work? >> c) What level of management should be exposed to the outside? >> d) Should it be possible to modify runtime behaviour of these servers >> (i.e. write access to config)? >> e) Should deployment be supported at all? >> f) How can a server be detected that has gone bad? >> g) Should logs be aggregated? >> h) Should there be a common management view (i.e. console) for these >> servers? >> i) etc ? >> >> Are these concerns already being addressed for WildFly? >> >> Is there perhaps even an already existing design that I could look at? >> >> Can such an effort be connected to the work that is going on in Fabric8? >> >> cheers >> ?thomas >> >> PS: it would be area that we @ wildfly-camel were interested to work on >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From tdiesler at redhat.com Wed Dec 17 10:58:11 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Wed, 17 Dec 2014 16:58:11 +0100 Subject: [wildfly-dev] Use management realm for webapp authentication Message-ID: <0A36E3BD-D110-46AA-80A3-4C7959B81E03@redhat.com> Folks, is it possible to use the ManagementRealm for webapp authentication? https://github.com/wildfly-extras/wildfly-camel/issues/182 cheers ?thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141217/e400bc07/attachment.html From tdiesler at redhat.com Wed Dec 17 11:13:29 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Wed, 17 Dec 2014 17:13:29 +0100 Subject: [wildfly-dev] WildFly domain on OpenShift Origin In-Reply-To: <5491964A.3040306@redhat.com> References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> <44C922B6-FD83-44DF-9DC5-87D7AED804DA@redhat.com> <5491964A.3040306@redhat.com> Message-ID: <0505563E-7A27-40F1-B1EC-B4AB273440F3@redhat.com> > On 17 Dec 2014, at 15:42, Brian Stansberry wrote: > > On 12/17/14, 3:28 AM, Thomas Diesler wrote: >> Folks, >> >> following up on this topic, I worked a little more on WildFly-Camel in >> Kubernetes/OpenShift. >> >> These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015) >> >> * WildFly-Camel on Docker >> >> * WildFly-Camel on OpenShift >> >> > > Great. :) > >> >> The setup looks like this >> >> >> We can now manage these individual wildfly nodes. The domain controller >> (DC) is replicated once, the host definition is replicated three times. >> Theoretically, this means that there is no single point of failure with >> the domain controller any more - kube would respawn the DC on failure >> > > I'm heading on PTO tomorrow so likely won't be able to follow up on this > question for a while, but one concern I had with the Kubernetes respawn > approach was retaining any changes that had been made to the domain > configuration. Unless the domain.xml comes from / is written to some > shared storage available to the respawned DC, any changes made will be lost. > > Of course, if the DC is only being used for reads, this isn't an issue. Yes, the management interface would need to detect whether a volume is used and perhaps issue a warning accordingly > >> Here some ideas for improvement ? >> >> In a kube env we should be able to swap out containers based on some >> criteria. It should be possible to define these criteria, emit events >> based on them create/remove/replace containers automatically. >> Additionally a human should be able to make qualified decisions through >> a console and create/remove/replace containers easily. >> Much of the needed information is in jmx. Heiko told me that there is a >> project that can push events to influx db - something to look at. >> >> If information display contained in jmx in a console has value (e.g in >> hawtio) that information must be aggregated and visible for each node. >> Currently, we have a round robin service on 8080 which would show a >> different hawtio instance on every request - this is nonsense. >> >> I can see a number of high level items: >> >> #1 a thing that aggregates jmx content - possibly multiple MBeanServers >> in the DC VM that delegate to respective MBeanServers on other hosts, so >> that a management client can pickup the info from one service >> #2 look at the existing inluxdb thing and research into how to automate >> the replacement of containers >> #3 from the usability perspective, there may need to be an openshift >> profile in the console(s) because some operations may not make sense in >> that env >> >> cheers >> ?thomas >> >> PS: looking forward to an exiting ride in 2015 >> >> >>> On 5 Dec 2014, at 14:36, Thomas Diesler >> > wrote: >>> >>> Folks, >>> >>> I?ve recently been looking at WildFly container deployments on >>> OpenShift V3. The following setup is documented here >>> >>> >>> >>> >>> The example architecture consists of a set of three high available >>> (HA) servers running REST endpoints. >>> For server replication and failover we use Kubernetes. Each server >>> runs in a dedicated Pod that we access via Services. >>> >>> This approach comes with a number of benefits, which are sufficiently >>> explained in various OpenShift >>> , >>> Kubernetes >>> and >>> Docker materials, but also with a number of >>> challenges. Lets look at those in more detail ? >>> >>> In the example above Kubernetes replicates a number of standalone >>> containers and isolates them in a Pod each with limited access from >>> the outside world. >>> >>> * The management interfaces are not accessible >>> * The management consoles are not visible >>> >>> With WildFly-Camel we have a Hawt.io >>> console >>> that allows us to manage Camel Routes configured or deployed to the >>> WildFly runtime. >>> The WildFly console manages aspects of the appserver. >>> >>> In a more general sense, I was wondering how the WildFly domain model >>> maps to the Kubernetes runtime environment and how these server >>> instances are managed and information about them relayed back to the >>> sysadmin >>> >>> a) Should these individual wildfly instances somehow be connected to >>> each other (i.e. notion of domain)? >>> b) How would an HA singleton service work? >>> c) What level of management should be exposed to the outside? >>> d) Should it be possible to modify runtime behaviour of these servers >>> (i.e. write access to config)? >>> e) Should deployment be supported at all? >>> f) How can a server be detected that has gone bad? >>> g) Should logs be aggregated? >>> h) Should there be a common management view (i.e. console) for these >>> servers? >>> i) etc ? >>> >>> Are these concerns already being addressed for WildFly? >>> >>> Is there perhaps even an already existing design that I could look at? >>> >>> Can such an effort be connected to the work that is going on in Fabric8? >>> >>> cheers >>> ?thomas >>> >>> PS: it would be area that we @ wildfly-camel were interested to work on >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > -- > Brian Stansberry > 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 wfink at redhat.com Wed Dec 17 13:05:08 2014 From: wfink at redhat.com (Wolf-Dieter Fink) Date: Wed, 17 Dec 2014 19:05:08 +0100 Subject: [wildfly-dev] bind the server against all interfaces "-b 0.0.0.0" or configuration In-Reply-To: References: <54905BC2.3070608@redhat.com> Message-ID: <5491C5D4.6030601@redhat.com> I'm not sure how to handle the "-b 0.0.0.0" This mean the "public" default interface is bound to ANY and this is used for jgroups bindings as well. From former versions the expectation is that either invocations (remoting http) or clustering (JGroups) works and it is possible to use other clients or nodes at localhost or connect via the real IP. I glanced over the docs but did not found a hint what the recommended way is here. Any thoughts? - Wolf On 16/12/14 21:58, Toma? Cerar wrote: > > On Tue, Dec 16, 2014 at 5:20 PM, Wolf-Dieter Fink > wrote: > > java.net.BindException: [UDP] /0.0.0.0 is not a > valid address on any > local network interface > > > > Mac OSX? if so that is known mac os/jdk limitation. ==> no Fedora > > The url stuff looks like a bug, non resolved expression is passed > over. Can you create jira for that. ===> https://issues.jboss.org/browse/WFLY-4188 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141217/d3a439f4/attachment.html From brian.stansberry at redhat.com Wed Dec 17 14:10:33 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 17 Dec 2014 13:10:33 -0600 Subject: [wildfly-dev] bind the server against all interfaces "-b 0.0.0.0" or configuration In-Reply-To: <5491C5D4.6030601@redhat.com> References: <54905BC2.3070608@redhat.com> <5491C5D4.6030601@redhat.com> Message-ID: <5491D529.8050902@redhat.com> https://developer.jboss.org/thread/201198 What you need to do is add another interface config not bound to IN_ADDR_ANY and change the jgroups socket binding configs to use that. The interface address ends up configuring the JGroups UDP.bind_addr value, and JGroups will not accept 0.0.0.0 for that, since it uses that parameter to determine the interface on which to *send* datagrams. If you want the UDP transport to use all available interfaces to receive multicast messages, set the "receive_on_all_interfaces" param to "true" in the UDP part of the JGroups subsystem config. On 12/17/14, 12:05 PM, Wolf-Dieter Fink wrote: > I'm not sure how to handle the "-b 0.0.0.0" > This mean the "public" default interface is bound to ANY and this is > used for jgroups bindings as well. > > From former versions the expectation is that either invocations > (remoting http) or clustering (JGroups) works and it is possible to use > other clients or nodes at localhost or connect via the real IP. > > I glanced over the docs but did not found a hint what the recommended > way is here. > > Any thoughts? > > - Wolf > > > On 16/12/14 21:58, Toma? Cerar wrote: >> >> On Tue, Dec 16, 2014 at 5:20 PM, Wolf-Dieter Fink > > wrote: >> >> java.net.BindException: [UDP] /0.0.0.0 is not a >> valid address on any >> local network interface >> >> >> >> Mac OSX? if so that is known mac os/jdk limitation. > ==> no Fedora >> >> The url stuff looks like a bug, non resolved expression is passed >> over. Can you create jira for that. > ===> https://issues.jboss.org/browse/WFLY-4188 > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ema at redhat.com Wed Dec 17 19:58:25 2014 From: ema at redhat.com (Jim Ma) Date: Thu, 18 Dec 2014 08:58:25 +0800 Subject: [wildfly-dev] Wildfly binary snapshot Message-ID: <549226B1.80305@redhat.com> Hi, When our community user wants to try the latest wildfly9 snapshot, does he or she have to git clone our code and build locally ? Can we set up a job to deploy snapshot binary/artifacts every day or every other day ? Cheers, Jim From brian.stansberry at redhat.com Wed Dec 17 20:48:54 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 17 Dec 2014 19:48:54 -0600 Subject: [wildfly-dev] Wildfly binary snapshot In-Reply-To: <549226B1.80305@redhat.com> References: <549226B1.80305@redhat.com> Message-ID: <54923286.6000803@redhat.com> https://developer.jboss.org/thread/224262 On 12/17/14, 6:58 PM, Jim Ma wrote: > Hi, > When our community user wants to try the latest wildfly9 snapshot, does > he or she have to git clone our code and build locally ? Can we set up a > job to deploy snapshot binary/artifacts every day or every other day ? > > Cheers, > Jim > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From claudio at claudius.com.br Wed Dec 17 20:51:11 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Wed, 17 Dec 2014 23:51:11 -0200 Subject: [wildfly-dev] Wildfly binary snapshot In-Reply-To: <549226B1.80305@redhat.com> References: <549226B1.80305@redhat.com> Message-ID: https://ci.jboss.org/hudson/job/WildFly-latest-master/ On Wed, Dec 17, 2014 at 10:58 PM, Jim Ma wrote: > Hi, > When our community user wants to try the latest wildfly9 snapshot, does > he or she have to git clone our code and build locally ? Can we set up a > job to deploy snapshot binary/artifacts every day or every other day ? > > Cheers, > Jim > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From ema at redhat.com Wed Dec 17 21:23:59 2014 From: ema at redhat.com (Jim Ma) Date: Thu, 18 Dec 2014 10:23:59 +0800 Subject: [wildfly-dev] Wildfly binary snapshot In-Reply-To: References: <549226B1.80305@redhat.com> Message-ID: <54923ABF.7090202@redhat.com> Thanks, Claudio and Brian. Do we have maven snapshot artifacts deployed ? On 12/18/2014 09:51 AM, Claudio Miranda wrote: > https://ci.jboss.org/hudson/job/WildFly-latest-master/ > > On Wed, Dec 17, 2014 at 10:58 PM, Jim Ma wrote: >> Hi, >> When our community user wants to try the latest wildfly9 snapshot, does >> he or she have to git clone our code and build locally ? Can we set up a >> job to deploy snapshot binary/artifacts every day or every other day ? >> >> Cheers, >> Jim >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From claudio at claudius.com.br Wed Dec 17 21:30:04 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Thu, 18 Dec 2014 00:30:04 -0200 Subject: [wildfly-dev] Wildfly binary snapshot In-Reply-To: <54923ABF.7090202@redhat.com> References: <549226B1.80305@redhat.com> <54923ABF.7090202@redhat.com> Message-ID: On Thu, Dec 18, 2014 at 12:23 AM, Jim Ma wrote: > Do we have maven snapshot artifacts deployed ? https://repository.jboss.org/nexus/content/groups/public/ -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From tdiesler at redhat.com Wed Dec 17 11:13:29 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Wed, 17 Dec 2014 17:13:29 +0100 Subject: [wildfly-dev] WildFly domain on OpenShift Origin In-Reply-To: <5491964A.3040306@redhat.com> References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> <44C922B6-FD83-44DF-9DC5-87D7AED804DA@redhat.com> <5491964A.3040306@redhat.com> Message-ID: <0505563E-7A27-40F1-B1EC-B4AB273440F3@redhat.com> > On 17 Dec 2014, at 15:42, Brian Stansberry wrote: > > On 12/17/14, 3:28 AM, Thomas Diesler wrote: >> Folks, >> >> following up on this topic, I worked a little more on WildFly-Camel in >> Kubernetes/OpenShift. >> >> These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015) >> >> * WildFly-Camel on Docker >> >> * WildFly-Camel on OpenShift >> >> > > Great. :) > >> >> The setup looks like this >> >> >> We can now manage these individual wildfly nodes. The domain controller >> (DC) is replicated once, the host definition is replicated three times. >> Theoretically, this means that there is no single point of failure with >> the domain controller any more - kube would respawn the DC on failure >> > > I'm heading on PTO tomorrow so likely won't be able to follow up on this > question for a while, but one concern I had with the Kubernetes respawn > approach was retaining any changes that had been made to the domain > configuration. Unless the domain.xml comes from / is written to some > shared storage available to the respawned DC, any changes made will be lost. > > Of course, if the DC is only being used for reads, this isn't an issue. Yes, the management interface would need to detect whether a volume is used and perhaps issue a warning accordingly > >> Here some ideas for improvement ? >> >> In a kube env we should be able to swap out containers based on some >> criteria. It should be possible to define these criteria, emit events >> based on them create/remove/replace containers automatically. >> Additionally a human should be able to make qualified decisions through >> a console and create/remove/replace containers easily. >> Much of the needed information is in jmx. Heiko told me that there is a >> project that can push events to influx db - something to look at. >> >> If information display contained in jmx in a console has value (e.g in >> hawtio) that information must be aggregated and visible for each node. >> Currently, we have a round robin service on 8080 which would show a >> different hawtio instance on every request - this is nonsense. >> >> I can see a number of high level items: >> >> #1 a thing that aggregates jmx content - possibly multiple MBeanServers >> in the DC VM that delegate to respective MBeanServers on other hosts, so >> that a management client can pickup the info from one service >> #2 look at the existing inluxdb thing and research into how to automate >> the replacement of containers >> #3 from the usability perspective, there may need to be an openshift >> profile in the console(s) because some operations may not make sense in >> that env >> >> cheers >> ?thomas >> >> PS: looking forward to an exiting ride in 2015 >> >> >>> On 5 Dec 2014, at 14:36, Thomas Diesler >> > wrote: >>> >>> Folks, >>> >>> I?ve recently been looking at WildFly container deployments on >>> OpenShift V3. The following setup is documented here >>> >>> >>> >>> >>> The example architecture consists of a set of three high available >>> (HA) servers running REST endpoints. >>> For server replication and failover we use Kubernetes. Each server >>> runs in a dedicated Pod that we access via Services. >>> >>> This approach comes with a number of benefits, which are sufficiently >>> explained in various OpenShift >>> , >>> Kubernetes >>> and >>> Docker materials, but also with a number of >>> challenges. Lets look at those in more detail ? >>> >>> In the example above Kubernetes replicates a number of standalone >>> containers and isolates them in a Pod each with limited access from >>> the outside world. >>> >>> * The management interfaces are not accessible >>> * The management consoles are not visible >>> >>> With WildFly-Camel we have a Hawt.io >>> console >>> that allows us to manage Camel Routes configured or deployed to the >>> WildFly runtime. >>> The WildFly console manages aspects of the appserver. >>> >>> In a more general sense, I was wondering how the WildFly domain model >>> maps to the Kubernetes runtime environment and how these server >>> instances are managed and information about them relayed back to the >>> sysadmin >>> >>> a) Should these individual wildfly instances somehow be connected to >>> each other (i.e. notion of domain)? >>> b) How would an HA singleton service work? >>> c) What level of management should be exposed to the outside? >>> d) Should it be possible to modify runtime behaviour of these servers >>> (i.e. write access to config)? >>> e) Should deployment be supported at all? >>> f) How can a server be detected that has gone bad? >>> g) Should logs be aggregated? >>> h) Should there be a common management view (i.e. console) for these >>> servers? >>> i) etc ? >>> >>> Are these concerns already being addressed for WildFly? >>> >>> Is there perhaps even an already existing design that I could look at? >>> >>> Can such an effort be connected to the work that is going on in Fabric8? >>> >>> cheers >>> ?thomas >>> >>> PS: it would be area that we @ wildfly-camel were interested to work on >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > -- > Brian Stansberry > 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 tdiesler at redhat.com Thu Dec 18 03:26:13 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Thu, 18 Dec 2014 09:26:13 +0100 Subject: [wildfly-dev] WildFly domain on OpenShift Origin In-Reply-To: References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> <44C922B6-FD83-44DF-9DC5-87D7AED804DA@redhat.com> <5491964A.3040306@redhat.com> <89148630-C30C-4783-8FFD-38F452DDE94A@redhat.com> Message-ID: <25721500-EF9C-43C0-A5EA-87988A8FB2F2@redhat.com> Lets start with requirements and a design that everybody who has a stake in this can be agreed on - I?ll get a doc started. > On 18 Dec 2014, at 09:18, James Strachan wrote: > > If the EAP console is available as a Kubernetes Service we can easily add it to the hawtio nav bar like we do with Kibana, Grafana et al. > >> On 17 Dec 2014, at 16:17, Thomas Diesler > wrote: >> >> Thanks James, >> >> I?ll look at the fabric8 hawtio console next I see if I can get it to work alongside with the wildfly console. Then I think I should meet with Heiko/Harald (for a long walk) and we talk about this some more. >> >> ?thomas >> >> >> >>> On 17 Dec 2014, at 15:59, James Strachan > wrote: >>> >>> A persistent volume could be used for the pod running the DC; if the pod is restarted or if it fails over to another host the persistent volume will be preserved (using one of the shared volume mechanisms in kubernetes/openshift like Ceph/Gluster/Cinder/S3/EBS etc) >>> >>>> On 17 Dec 2014, at 14:42, Brian Stansberry > wrote: >>>> >>>> On 12/17/14, 3:28 AM, Thomas Diesler wrote: >>>>> Folks, >>>>> >>>>> following up on this topic, I worked a little more on WildFly-Camel in >>>>> Kubernetes/OpenShift. >>>>> >>>>> These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015) >>>>> >>>>> * WildFly-Camel on Docker >>>>> > >>>>> * WildFly-Camel on OpenShift >>>>> > >>>>> >>>> >>>> Great. :) >>>> >>>>> >>>>> The setup looks like this >>>>> >>>>> >>>>> We can now manage these individual wildfly nodes. The domain controller >>>>> (DC) is replicated once, the host definition is replicated three times. >>>>> Theoretically, this means that there is no single point of failure with >>>>> the domain controller any more - kube would respawn the DC on failure >>>>> >>>> >>>> I'm heading on PTO tomorrow so likely won't be able to follow up on this question for a while, but one concern I had with the Kubernetes respawn approach was retaining any changes that had been made to the domain configuration. Unless the domain.xml comes from / is written to some shared storage available to the respawned DC, any changes made will be lost. >>>> >>>> Of course, if the DC is only being used for reads, this isn't an issue. >>>> >>>>> Here some ideas for improvement ? >>>>> >>>>> In a kube env we should be able to swap out containers based on some >>>>> criteria. It should be possible to define these criteria, emit events >>>>> based on them create/remove/replace containers automatically. >>>>> Additionally a human should be able to make qualified decisions through >>>>> a console and create/remove/replace containers easily. >>>>> Much of the needed information is in jmx. Heiko told me that there is a >>>>> project that can push events to influx db - something to look at. >>>>> >>>>> If information display contained in jmx in a console has value (e.g in >>>>> hawtio) that information must be aggregated and visible for each node. >>>>> Currently, we have a round robin service on 8080 which would show a >>>>> different hawtio instance on every request - this is nonsense. >>>>> >>>>> I can see a number of high level items: >>>>> >>>>> #1 a thing that aggregates jmx content - possibly multiple MBeanServers >>>>> in the DC VM that delegate to respective MBeanServers on other hosts, so >>>>> that a management client can pickup the info from one service >>>>> #2 look at the existing inluxdb thing and research into how to automate >>>>> the replacement of containers >>>>> #3 from the usability perspective, there may need to be an openshift >>>>> profile in the console(s) because some operations may not make sense in >>>>> that env >>>>> >>>>> cheers >>>>> ?thomas >>>>> >>>>> PS: looking forward to an exiting ride in 2015 >>>>> >>>>> >>>>>> On 5 Dec 2014, at 14:36, Thomas Diesler >>>>>> >> wrote: >>>>>> >>>>>> Folks, >>>>>> >>>>>> I?ve recently been looking at WildFly container deployments on >>>>>> OpenShift V3. The following setup is documented here >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> The example architecture consists of a set of three high available >>>>>> (HA) servers running REST endpoints. >>>>>> For server replication and failover we use Kubernetes. Each server >>>>>> runs in a dedicated Pod that we access via Services. >>>>>> >>>>>> This approach comes with a number of benefits, which are sufficiently >>>>>> explained in various OpenShift >>>>>> >, >>>>>> Kubernetes >>>>>> > and >>>>>> Docker > materials, but also with a number of >>>>>> challenges. Lets look at those in more detail ? >>>>>> >>>>>> In the example above Kubernetes replicates a number of standalone >>>>>> containers and isolates them in a Pod each with limited access from >>>>>> the outside world. >>>>>> >>>>>> * The management interfaces are not accessible >>>>>> * The management consoles are not visible >>>>>> >>>>>> With WildFly-Camel we have a Hawt.io >>>>>> > console >>>>>> that allows us to manage Camel Routes configured or deployed to the >>>>>> WildFly runtime. >>>>>> The WildFly console manages aspects of the appserver. >>>>>> >>>>>> In a more general sense, I was wondering how the WildFly domain model >>>>>> maps to the Kubernetes runtime environment and how these server >>>>>> instances are managed and information about them relayed back to the >>>>>> sysadmin >>>>>> >>>>>> a) Should these individual wildfly instances somehow be connected to >>>>>> each other (i.e. notion of domain)? >>>>>> b) How would an HA singleton service work? >>>>>> c) What level of management should be exposed to the outside? >>>>>> d) Should it be possible to modify runtime behaviour of these servers >>>>>> (i.e. write access to config)? >>>>>> e) Should deployment be supported at all? >>>>>> f) How can a server be detected that has gone bad? >>>>>> g) Should logs be aggregated? >>>>>> h) Should there be a common management view (i.e. console) for these >>>>>> servers? >>>>>> i) etc ? >>>>>> >>>>>> Are these concerns already being addressed for WildFly? >>>>>> >>>>>> Is there perhaps even an already existing design that I could look at? >>>>>> >>>>>> Can such an effort be connected to the work that is going on in Fabric8? >>>>>> >>>>>> cheers >>>>>> ?thomas >>>>>> >>>>>> PS: it would be area that we @ wildfly-camel were interested to work on >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Senior Principal Software Engineer >>>> JBoss by Red Hat >>> >>> >>> James >>> ------- >>> Red Hat >>> >>> Twitter: @jstrachan >>> Email: jstracha at redhat.com >>> Blog: http://macstrac.blogspot.com/ >>> >>> hawtio: http://hawt.io/ >>> fabric8: http://fabric8.io/ >>> >>> Open Source Integration >>> >> > > > James > ------- > Red Hat > > Twitter: @jstrachan > Email: jstracha at redhat.com > Blog: http://macstrac.blogspot.com/ > > hawtio: http:/ /hawt.io/ > fabric8: http:/ /fabric8.io/ > > Open Source Integration > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141218/9e729970/attachment-0001.html From asoldano at redhat.com Thu Dec 18 04:43:10 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Thu, 18 Dec 2014 10:43:10 +0100 Subject: [wildfly-dev] Wildfly binary snapshot In-Reply-To: References: <549226B1.80305@redhat.com> <54923ABF.7090202@redhat.com> Message-ID: <5492A1AE.7080803@redhat.com> On 18/12/14 03:30, Claudio Miranda wrote: > On Thu, Dec 18, 2014 at 12:23 AM, Jim Ma wrote: >> Do we have maven snapshot artifacts deployed ? > https://repository.jboss.org/nexus/content/groups/public/ > I think what Jim is looking for is the latest snapshot version for the stuff here: https://repository.jboss.org/nexus/content/groups/public/org/wildfly/wildfly-dist/ There are released versions only there. Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From tomaz.cerar at gmail.com Thu Dec 18 05:53:18 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 18 Dec 2014 11:53:18 +0100 Subject: [wildfly-dev] Wildfly binary snapshot In-Reply-To: <54923ABF.7090202@redhat.com> References: <549226B1.80305@redhat.com> <54923ABF.7090202@redhat.com> Message-ID: No we do not publish nightly snapshots to maven repo. As this would be a big burden on storage & nexus performance. On Thu, Dec 18, 2014 at 3:23 AM, Jim Ma wrote: > > Thanks, Claudio and Brian. Do we have maven snapshot artifacts deployed ? > > On 12/18/2014 09:51 AM, Claudio Miranda wrote: > > https://ci.jboss.org/hudson/job/WildFly-latest-master/ > > > > On Wed, Dec 17, 2014 at 10:58 PM, Jim Ma wrote: > >> Hi, > >> When our community user wants to try the latest wildfly9 snapshot, does > >> he or she have to git clone our code and build locally ? Can we set up a > >> job to deploy snapshot binary/artifacts every day or every other day ? > >> > >> Cheers, > >> Jim > >> _______________________________________________ > >> 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/20141218/d9770b60/attachment.html From ema at redhat.com Thu Dec 18 06:41:29 2014 From: ema at redhat.com (Jim Ma) Date: Thu, 18 Dec 2014 19:41:29 +0800 Subject: [wildfly-dev] Wildfly binary snapshot In-Reply-To: References: <549226B1.80305@redhat.com> <54923ABF.7090202@redhat.com> Message-ID: <5492BD69.8020504@redhat.com> So we need a separated storage and nexus server to place snapshot artifacts ? Is there a plan to setup one? This is required if other project wants to catch up with wildfly latest change and depends on snapshot artifact. On 12/18/2014 06:53 PM, Toma? Cerar wrote: > No we do not publish nightly snapshots to maven repo. > As this would be a big burden on storage & nexus performance. > > On Thu, Dec 18, 2014 at 3:23 AM, Jim Ma > wrote: > > Thanks, Claudio and Brian. Do we have maven snapshot artifacts > deployed ? > > On 12/18/2014 09:51 AM, Claudio Miranda wrote: > > https://ci.jboss.org/hudson/job/WildFly-latest-master/ > > > > On Wed, Dec 17, 2014 at 10:58 PM, Jim Ma > wrote: > >> Hi, > >> When our community user wants to try the latest wildfly9 > snapshot, does > >> he or she have to git clone our code and build locally ? Can we > set up a > >> job to deploy snapshot binary/artifacts every day or every > other day ? > >> > >> Cheers, > >> Jim > >> _______________________________________________ > >> 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/20141218/f07e2a85/attachment.html From tomaz.cerar at gmail.com Thu Dec 18 08:20:33 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 18 Dec 2014 14:20:33 +0100 Subject: [wildfly-dev] Wildfly binary snapshot In-Reply-To: <5492BD69.8020504@redhat.com> References: <549226B1.80305@redhat.com> <54923ABF.7090202@redhat.com> <5492BD69.8020504@redhat.com> Message-ID: I see no real need for that as this wouldn't provide any good usage pattern for anyone. If your code builds upon wildfly snapshot that is fine, but you should build wildfly locally for that. As having (public) code depend on snapshot is not really a good practice as it can result in non reproducible build. You do have 9.0.0.Alpha1 published, and soon there will be Beta1 out which are preview versions that you should build upon. On Thu, Dec 18, 2014 at 12:41 PM, Jim Ma wrote: > > So we need a separated storage and nexus server to place snapshot > artifacts ? Is there a plan to setup one? > This is required if other project wants to catch up with wildfly latest > change and depends on snapshot artifact. > On 12/18/2014 06:53 PM, Toma? Cerar wrote: > > No we do not publish nightly snapshots to maven repo. > As this would be a big burden on storage & nexus performance. > > On Thu, Dec 18, 2014 at 3:23 AM, Jim Ma wrote: >> >> Thanks, Claudio and Brian. Do we have maven snapshot artifacts deployed ? >> >> On 12/18/2014 09:51 AM, Claudio Miranda wrote: >> > https://ci.jboss.org/hudson/job/WildFly-latest-master/ >> > >> > On Wed, Dec 17, 2014 at 10:58 PM, Jim Ma wrote: >> >> Hi, >> >> When our community user wants to try the latest wildfly9 snapshot, does >> >> he or she have to git clone our code and build locally ? Can we set up >> a >> >> job to deploy snapshot binary/artifacts every day or every other day ? >> >> >> >> Cheers, >> >> Jim >> >> _______________________________________________ >> >> 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/20141218/239abc7b/attachment.html From jose.e.chavez at gmail.com Thu Dec 18 08:31:11 2014 From: jose.e.chavez at gmail.com (jose.e.chavez at gmail.com) Date: Thu, 18 Dec 2014 07:31:11 -0600 Subject: [wildfly-dev] Differences between Wildfly 8.2 and 9.0? Message-ID: <20141218133111.6033555.56637.10251@gmail.com> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141218/733d0e7b/attachment.html From ema at redhat.com Fri Dec 19 02:55:22 2014 From: ema at redhat.com (Er Qiang (Jim) Ma) Date: Fri, 19 Dec 2014 02:55:22 -0500 (EST) Subject: [wildfly-dev] Wildfly binary snapshot In-Reply-To: References: <549226B1.80305@redhat.com> <54923ABF.7090202@redhat.com> <5492BD69.8020504@redhat.com> Message-ID: <1947067014.858059.1418975722958.JavaMail.zimbra@redhat.com> We are testing wildfly snapshot with our latest jbossws-cxf. It requires us to pull wildfly and build locally each time before we run the jbossws test suite. If there is wildfly snapshot binary zip can be deployed to maven repo, we can unpack the binary in our maven build. ----- Original Message ----- From: "Toma? Cerar" To: "Jim Ma" Cc: "Claudio Miranda" , wildfly-dev at lists.jboss.org Sent: Thursday, December 18, 2014 9:20:33 PM Subject: Re: [wildfly-dev] Wildfly binary snapshot I see no real need for that as this wouldn't provide any good usage pattern for anyone. If your code builds upon wildfly snapshot that is fine, but you should build wildfly locally for that. As having (public) code depend on snapshot is not really a good practice as it can result in non reproducible build. You do have 9.0.0.Alpha1 published, and soon there will be Beta1 out which are preview versions that you should build upon. On Thu, Dec 18, 2014 at 12:41 PM, Jim Ma wrote: > > So we need a separated storage and nexus server to place snapshot > artifacts ? Is there a plan to setup one? > This is required if other project wants to catch up with wildfly latest > change and depends on snapshot artifact. > On 12/18/2014 06:53 PM, Toma? Cerar wrote: > > No we do not publish nightly snapshots to maven repo. > As this would be a big burden on storage & nexus performance. > > On Thu, Dec 18, 2014 at 3:23 AM, Jim Ma wrote: >> >> Thanks, Claudio and Brian. Do we have maven snapshot artifacts deployed ? >> >> On 12/18/2014 09:51 AM, Claudio Miranda wrote: >> > https://ci.jboss.org/hudson/job/WildFly-latest-master/ >> > >> > On Wed, Dec 17, 2014 at 10:58 PM, Jim Ma wrote: >> >> Hi, >> >> When our community user wants to try the latest wildfly9 snapshot, does >> >> he or she have to git clone our code and build locally ? Can we set up >> a >> >> job to deploy snapshot binary/artifacts every day or every other day ? >> >> >> >> Cheers, >> >> Jim >> >> _______________________________________________ >> >> 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 >> > >