From brian.stansberry at redhat.com Wed Oct 1 10:52:57 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 01 Oct 2014 09:52:57 -0500 Subject: [wildfly-dev] Steamable content in management API responses Message-ID: <542C1549.2000500@redhat.com> tl;dr I'm looking into supported streamed content in management API responses and wanted to get feedback. The admin console has a need for a streamed response, as we have a requirement to let a user download a log file to store on local disk. The browser can itself directly download a file using HTTP, but will not let an app like the console make multiple DMR requests and itself append data from the responses to a file on disk. There are other likely uses cases for a similar thing, e.g. reading the contents of the content (aka deployment) repository. We already support attaching streams to requests; the proposal is to do much the same with responses. For HTTP clients, if a request is for something that attaches a stream to the response, the request URL can include a query param instructing the server to pipe the stream for the response instead of sending the standard JSON reponse value. Long version: Requirements: 1) Ability to send arbitrarily long amounts of data in management responses. Currently everything in a management response has to be encodable in DMR. DMR will allow you to send a byte[] as a response value, but for memory reasons this isn't a practical approach for large responses. 2) Ability to send the data directly to an HTTP request, not wrapped in a JSON wrapper. Even if we would include a huge value as a JSON encoded byte[], a browser won't let an app like the console read those bytes out of the JSON response and write them to disk. A direct response to an HTTP GET/POST is needed. 3) Works for other remoting-based clients as well. This is a basic requirement that HTTP and remoting-based clients can each do everything. So, no HTTP only side features. 4) Requests go through the central management layer, so we have proper security, audit logging etc. So, no special endpoints that bypass the core management layer. Proposal: We already support attaching a stream to the request for native clients. (This is how the CLI does deployments.) The client API lets the client associate a stream with the request[1]. The stream has an index. The operation that needs the stream takes a DMR param that tells it the index of the stream. On the server side the handler uses that param value to find the server-side representation of the stream. The remoting layer of the remote management protocol in the background handles piping the contents of the client side stream to the server. The proposal is to simply mirror this in reverse. A server side operation handler associates a stream with the response (via a call on the OperationContext). The attached stream has an index. The normal DMR response to the operation is the index of the stream. The client uses that response value to find the attached stream. The remoting layer of the remote management protocol in the background handles piping the contents of the server side stream to the client. This handles remoting based clients, including those using http upgrade. For HTTP clients, the client can include a "useStreamAsResponse" query param in the request URL. If this is present, the server side endpoint will take the stream from the internal response and pipe it to the client, instead of sending the normal JSON. For example, a fictitious URL for a "stream-log-file" op against a resource that represents the server.log file: http://localhost:9090/management/subsystem/logging/log-file/server.log?operation=stream-log-file&useStreamAsResponse In the corner case where a request results in more than one attached response, the useStreamAsResponse could include an index. useStreamAsResponse=1 Status: It was reasonably straightforward to get this working, as a fairly polished prototype: https://github.com/bstansberry/wildfly-core/commits/resp-stream The 2nd commit there just hacks in an attribute to the logging subsystem root resource to expose the server log as a stream. There's no intent to actually do it that specific way of course; it was just an easy way to demonstrate. With that built an HTTP GET will download the log file to your desktop. http://localhost:9990/management/subsystem/logging?operation=attribute&name=server-log&useStreamAsResponse The native interface works as well. The 2nd commit includes a test case that confirms this. So the CLI easily enough could add a high level command for log reading too. TODOs: 1) Domain mode: proxy the streams around the domain (server->HC->DC->client). I think this should be quite easy. 2) A cleaner variant of the remoting-based management protocol for handling the streams, one that doesn't require hacks to determine the length of the stream in advance. Should be relatively straightforward. 3) Logic to clean up server side streams if the client doesn't properly consume them. 4) Make sure there a no issues with the thread pools used to handle management requests. 5) Make sure POST works well. My assumption is this is lower priority, as the real use cases would likely use a GET. [1] https://github.com/wildfly/wildfly-core/blob/master/controller-client/src/main/java/org/jboss/as/controller/client/OperationBuilder.java -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From wildfly at cobraflow.com Thu Oct 2 06:17:32 2014 From: wildfly at cobraflow.com (CobraFlow) Date: Thu, 2 Oct 2014 03:17:32 -0700 (PDT) Subject: [wildfly-dev] byteman In-Reply-To: References: Message-ID: <1412245052527-5715025.post@n5.nabble.com> Did you ever get this sorted? I ran into the same/similar problem. My cause was that I was adding JAVA_OPTS manually and this overrides the default which includes :- -Djboss.modules.system.pkgs=org.jboss.byteman ...which is required! Cheers -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/byteman-tp5711955p5715025.html Sent from the WildFly Development mailing list archive at Nabble.com. From david.lloyd at redhat.com Thu Oct 2 12:06:51 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 02 Oct 2014 11:06:51 -0500 Subject: [wildfly-dev] About the security manager lifecycle In-Reply-To: <54258BEF.40802@redhat.com> References: <54258BEF.40802@redhat.com> Message-ID: <542D781B.9050108@redhat.com> Hearing no objections, and finding yet more reasons to do so, I'm moving ahead with this. The security manager will be enabled at boot by giving the -secmgr flag to the startup script. The security manager subsystem will configure permissions only. On 09/26/2014 10:53 AM, David M. Lloyd wrote: > At present in WildFly upstream, the security manager is only installed > when the security manager subsystem installation commences, leading to > PRs like this one [1] being rejected. However, feedback from various > quarters indicates that this relatively late installation may not be > acceptable for a couple different reasons. The current EAP version > supports using the -secmgr flag to the start scripts to tell the > bootstrap to install the security manager via jboss-modules' discovery > process, which happens at the very beginning of process start. > > I'm thinking maybe we should bring this functionality forward, resurrect > #175, and modify the security manager subsystem to attach to the > currently installed security manager. This is also more friendly to > embedded processes; we should support (for example) permission > specification in deployments even if we don't directly control the > security manager. This also allows the security manager subsystem to > run even if no security manager is installed, so validation of > permissions.xml (for example) will still take place. > > Thoughts? > > [1] https://github.com/wildfly/wildfly-core/pull/175 > -- - DML From brian.stansberry at redhat.com Thu Oct 2 18:46:03 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 02 Oct 2014 17:46:03 -0500 Subject: [wildfly-dev] Steamable content in management API responses In-Reply-To: <542C1549.2000500@redhat.com> References: <542C1549.2000500@redhat.com> Message-ID: <542DD5AB.9060603@redhat.com> On 10/1/14, 9:52 AM, Brian Stansberry wrote: > > TODOs: > > > 5) Make sure POST works well. My assumption is this is lower priority, > as the real use cases would likely use a GET. > If you include the useStreamAsResponse as a query param in the URL, as with GET, it works. If you do the proper POST thing and encode the query param in the request body it doesn't. The DomainApiHandler tries to parse the entire request body into a ModelNode and a leading useStreamAsResponse& or trailing &useStreamAsResponse fails. I'm fine with just requiring encoding the param in the URL, even though it isn't proper. I don't plan on spending energy near term on parsing it out of a POST request body. If you're curious to try this with my resp-stream branch, this works: curl --digest -L -D - http://localhost:9990/management?useStreamAsResponse --header "Content-Type: application/json" -u user:password -d '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' This doesn't: curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -u user:password -d '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' -d useStreamAsResponse -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Thu Oct 2 19:00:14 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 02 Oct 2014 18:00:14 -0500 Subject: [wildfly-dev] Steamable content in management API responses In-Reply-To: <542DD5AB.9060603@redhat.com> References: <542C1549.2000500@redhat.com> <542DD5AB.9060603@redhat.com> Message-ID: <542DD8FE.6060702@redhat.com> On 10/02/2014 05:46 PM, Brian Stansberry wrote: > On 10/1/14, 9:52 AM, Brian Stansberry wrote: > > >> >> TODOs: >> > >> >> 5) Make sure POST works well. My assumption is this is lower priority, >> as the real use cases would likely use a GET. >> > > If you include the useStreamAsResponse as a query param in the URL, as > with GET, it works. If you do the proper POST thing and encode the query > param in the request body it doesn't. The DomainApiHandler tries to > parse the entire request body into a ModelNode and a leading > useStreamAsResponse& or trailing &useStreamAsResponse fails. > > I'm fine with just requiring encoding the param in the URL, even though > it isn't proper. I don't plan on spending energy near term on parsing it > out of a POST request body. > > If you're curious to try this with my resp-stream branch, this works: > > curl --digest -L -D - > http://localhost:9990/management?useStreamAsResponse --header > "Content-Type: application/json" -u user:password -d > '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' > > This doesn't: > > curl --digest -L -D - http://localhost:9990/management --header > "Content-Type: application/json" -u user:password -d > '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' > -d useStreamAsResponse Maybe because the content type isn't multipart/form-data? I think if you're going to send or receive content alongside the main payload, you'll have to use a multipart request and/or response (this also implies some accept-ish header stuff too IIRC). -- - DML From jgreene at redhat.com Thu Oct 2 20:46:13 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Thu, 2 Oct 2014 20:46:13 -0400 (EDT) Subject: [wildfly-dev] Steamable content in management API responses In-Reply-To: <542DD8FE.6060702@redhat.com> References: <542C1549.2000500@redhat.com> <542DD5AB.9060603@redhat.com> <542DD8FE.6060702@redhat.com> Message-ID: It's proper. It's sending a content type of application/JSON not form data. So if you want the value other than the URL param, it would have to be in the DMR and read from the model node >> On Oct 2, 2014, at 6:01 PM, David M. Lloyd wrote: >> >> On 10/02/2014 05:46 PM, Brian Stansberry wrote: >> On 10/1/14, 9:52 AM, Brian Stansberry wrote: >> >> >>> >>> TODOs: >> >>> >>> 5) Make sure POST works well. My assumption is this is lower priority, >>> as the real use cases would likely use a GET. >> >> If you include the useStreamAsResponse as a query param in the URL, as >> with GET, it works. If you do the proper POST thing and encode the query >> param in the request body it doesn't. The DomainApiHandler tries to >> parse the entire request body into a ModelNode and a leading >> useStreamAsResponse& or trailing &useStreamAsResponse fails. >> >> I'm fine with just requiring encoding the param in the URL, even though >> it isn't proper. I don't plan on spending energy near term on parsing it >> out of a POST request body. >> >> If you're curious to try this with my resp-stream branch, this works: >> >> curl --digest -L -D - >> http://localhost:9990/management?useStreamAsResponse --header >> "Content-Type: application/json" -u user:password -d >> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' >> >> This doesn't: >> >> curl --digest -L -D - http://localhost:9990/management --header >> "Content-Type: application/json" -u user:password -d >> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' >> -d useStreamAsResponse > > Maybe because the content type isn't multipart/form-data? I think if > you're going to send or receive content alongside the main payload, > you'll have to use a multipart request and/or response (this also > implies some accept-ish header stuff too IIRC). > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Fri Oct 3 18:41:12 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 03 Oct 2014 17:41:12 -0500 Subject: [wildfly-dev] Steamable content in management API responses In-Reply-To: References: <542C1549.2000500@redhat.com> <542DD5AB.9060603@redhat.com> <542DD8FE.6060702@redhat.com> Message-ID: <542F2608.2050107@redhat.com> FYI, https://issues.jboss.org/browse/WFCORE-148 is the JIRA for this. I didn't want to encode useStreamAsResponse in the DMR as an operation header, as this isn't about how the core management layer executes the op, just how the http server deals with sending the response. But since it's Friday you guys inspired me to go ahead and handle application/x-www-form-urlencoded So I updated my branch and with the 3rd commit, a proper form with the DMR as the value associated with a form key 'dmr' now works: curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/x-www-form-urlencoded" -u bstansberry:admin.1234 -d 'dmr={"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' -d useStreamAsResponse A caller sending dmr-encoded can even hint at that with the "Accept" header: curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/x-www-form-urlencoded" --header "Accept: application/dmr-encoded" -u bstansberry:admin.1234 -d 'dmr=bwAAAAQACW9wZXJhdGlvbnMADnJlYWQtYXR0cmlidXRlAAdhZGRyZXNzbAAAAAFvAAAAAQAJc3Vic3lzdGVtcwAHbG9nZ2luZwAEbmFtZXMACnNlcnZlci1sb2cAC2pzb24ucHJldHR5SQAAAAE=' -d useStreamAsResponse That hack of using 'Accept' and not just 'Content-Type' to trigger dmr-encoded handling was already there, so don't blame me. ;) On 10/2/14, 7:46 PM, Jason T. Greene wrote: > It's proper. It's sending a content type of application/JSON not form data. So if you want the value other than the URL param, it would have to be in the DMR and read from the model node > >>> On Oct 2, 2014, at 6:01 PM, David M. Lloyd wrote: >>> >>> On 10/02/2014 05:46 PM, Brian Stansberry wrote: >>> On 10/1/14, 9:52 AM, Brian Stansberry wrote: >>> >>> >>>> >>>> TODOs: >>> >>>> >>>> 5) Make sure POST works well. My assumption is this is lower priority, >>>> as the real use cases would likely use a GET. >>> >>> If you include the useStreamAsResponse as a query param in the URL, as >>> with GET, it works. If you do the proper POST thing and encode the query >>> param in the request body it doesn't. The DomainApiHandler tries to >>> parse the entire request body into a ModelNode and a leading >>> useStreamAsResponse& or trailing &useStreamAsResponse fails. >>> >>> I'm fine with just requiring encoding the param in the URL, even though >>> it isn't proper. I don't plan on spending energy near term on parsing it >>> out of a POST request body. >>> >>> If you're curious to try this with my resp-stream branch, this works: >>> >>> curl --digest -L -D - >>> http://localhost:9990/management?useStreamAsResponse --header >>> "Content-Type: application/json" -u user:password -d >>> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' >>> >>> This doesn't: >>> >>> curl --digest -L -D - http://localhost:9990/management --header >>> "Content-Type: application/json" -u user:password -d >>> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' >>> -d useStreamAsResponse >> >> Maybe because the content type isn't multipart/form-data? I think if >> you're going to send or receive content alongside the main payload, >> you'll have to use a multipart request and/or response (this also >> implies some accept-ish header stuff too IIRC). >> -- >> - DML >> _______________________________________________ >> 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jgreene at redhat.com Sat Oct 4 22:11:05 2014 From: jgreene at redhat.com (Jason T. Greene) Date: Sat, 4 Oct 2014 22:11:05 -0400 (EDT) Subject: [wildfly-dev] Steamable content in management API responses In-Reply-To: <542F2608.2050107@redhat.com> References: <542C1549.2000500@redhat.com> <542DD5AB.9060603@redhat.com> <542DD8FE.6060702@redhat.com> <542F2608.2050107@redhat.com> Message-ID: <251CC9F3-2782-4CE4-81BD-1B7C2E2C032F@redhat.com> DMR as a form encoded value? I really don't think we should allow this. Form encoding is for web browsers typing in values and it will set off the extra security checks we have for cross origin posting (this is the kind of thing a JS hack would do to get your browser to send up arbitrary management ops to the server) We probably should use an HTTP header if we don't want it in the payload, perhaps in combination with an Accept. > On Oct 3, 2014, at 5:41 PM, Brian Stansberry wrote: > > FYI, https://issues.jboss.org/browse/WFCORE-148 is the JIRA for this. > > I didn't want to encode useStreamAsResponse in the DMR as an operation > header, as this isn't about how the core management layer executes the > op, just how the http server deals with sending the response. > > But since it's Friday you guys inspired me to go ahead and handle > application/x-www-form-urlencoded > > So I updated my branch and with the 3rd commit, a proper form with the > DMR as the value associated with a form key 'dmr' now works: > > curl --digest -L -D - http://localhost:9990/management --header > "Content-Type: application/x-www-form-urlencoded" -u > bstansberry:admin.1234 -d > 'dmr={"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' > -d useStreamAsResponse > > A caller sending dmr-encoded can even hint at that with the "Accept" header: > > curl --digest -L -D - http://localhost:9990/management --header > "Content-Type: application/x-www-form-urlencoded" --header "Accept: > application/dmr-encoded" -u bstansberry:admin.1234 -d > 'dmr=bwAAAAQACW9wZXJhdGlvbnMADnJlYWQtYXR0cmlidXRlAAdhZGRyZXNzbAAAAAFvAAAAAQAJc3Vic3lzdGVtcwAHbG9nZ2luZwAEbmFtZXMACnNlcnZlci1sb2cAC2pzb24ucHJldHR5SQAAAAE=' > -d useStreamAsResponse > > That hack of using 'Accept' and not just 'Content-Type' to trigger > dmr-encoded handling was already there, so don't blame me. ;) > >> On 10/2/14, 7:46 PM, Jason T. Greene wrote: >> It's proper. It's sending a content type of application/JSON not form data. So if you want the value other than the URL param, it would have to be in the DMR and read from the model node >> >>>> On Oct 2, 2014, at 6:01 PM, David M. Lloyd wrote: >>>> >>>> On 10/02/2014 05:46 PM, Brian Stansberry wrote: >>>> On 10/1/14, 9:52 AM, Brian Stansberry wrote: >>>> >>>> >>>>> >>>>> TODOs: >>>> >>>>> >>>>> 5) Make sure POST works well. My assumption is this is lower priority, >>>>> as the real use cases would likely use a GET. >>>> >>>> If you include the useStreamAsResponse as a query param in the URL, as >>>> with GET, it works. If you do the proper POST thing and encode the query >>>> param in the request body it doesn't. The DomainApiHandler tries to >>>> parse the entire request body into a ModelNode and a leading >>>> useStreamAsResponse& or trailing &useStreamAsResponse fails. >>>> >>>> I'm fine with just requiring encoding the param in the URL, even though >>>> it isn't proper. I don't plan on spending energy near term on parsing it >>>> out of a POST request body. >>>> >>>> If you're curious to try this with my resp-stream branch, this works: >>>> >>>> curl --digest -L -D - >>>> http://localhost:9990/management?useStreamAsResponse --header >>>> "Content-Type: application/json" -u user:password -d >>>> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' >>>> >>>> This doesn't: >>>> >>>> curl --digest -L -D - http://localhost:9990/management --header >>>> "Content-Type: application/json" -u user:password -d >>>> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' >>>> -d useStreamAsResponse >>> >>> Maybe because the content type isn't multipart/form-data? I think if >>> you're going to send or receive content alongside the main payload, >>> you'll have to use a multipart request and/or response (this also >>> implies some accept-ish header stuff too IIRC). >>> -- >>> - DML >>> _______________________________________________ >>> 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 > > > -- > 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 brian.stansberry at redhat.com Mon Oct 6 14:09:45 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 06 Oct 2014 13:09:45 -0500 Subject: [wildfly-dev] Steamable content in management API responses In-Reply-To: <251CC9F3-2782-4CE4-81BD-1B7C2E2C032F@redhat.com> References: <542C1549.2000500@redhat.com> <542DD5AB.9060603@redhat.com> <542DD8FE.6060702@redhat.com> <542F2608.2050107@redhat.com> <251CC9F3-2782-4CE4-81BD-1B7C2E2C032F@redhat.com> Message-ID: <5432DAE9.2030909@redhat.com> Ok, good to know. I'll just support a custom HTTP header. The query param in the URL works too, so people can choose the approach they want. On 10/4/14, 9:11 PM, Jason T. Greene wrote: > DMR as a form encoded value? I really don't think we should allow this. Form encoding is for web browsers typing in values and it will set off the extra security checks we have for cross origin posting (this is the kind of thing a JS hack would do to get your browser to send up arbitrary management ops to the server) > > We probably should use an HTTP header if we don't want it in the payload, perhaps in combination with an Accept. > > >> On Oct 3, 2014, at 5:41 PM, Brian Stansberry wrote: >> >> FYI, https://issues.jboss.org/browse/WFCORE-148 is the JIRA for this. >> >> I didn't want to encode useStreamAsResponse in the DMR as an operation >> header, as this isn't about how the core management layer executes the >> op, just how the http server deals with sending the response. >> >> But since it's Friday you guys inspired me to go ahead and handle >> application/x-www-form-urlencoded >> >> So I updated my branch and with the 3rd commit, a proper form with the >> DMR as the value associated with a form key 'dmr' now works: >> >> curl --digest -L -D - http://localhost:9990/management --header >> "Content-Type: application/x-www-form-urlencoded" -u >> bstansberry:admin.1234 -d >> 'dmr={"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' >> -d useStreamAsResponse >> >> A caller sending dmr-encoded can even hint at that with the "Accept" header: >> >> curl --digest -L -D - http://localhost:9990/management --header >> "Content-Type: application/x-www-form-urlencoded" --header "Accept: >> application/dmr-encoded" -u bstansberry:admin.1234 -d >> 'dmr=bwAAAAQACW9wZXJhdGlvbnMADnJlYWQtYXR0cmlidXRlAAdhZGRyZXNzbAAAAAFvAAAAAQAJc3Vic3lzdGVtcwAHbG9nZ2luZwAEbmFtZXMACnNlcnZlci1sb2cAC2pzb24ucHJldHR5SQAAAAE=' >> -d useStreamAsResponse >> >> That hack of using 'Accept' and not just 'Content-Type' to trigger >> dmr-encoded handling was already there, so don't blame me. ;) >> >>> On 10/2/14, 7:46 PM, Jason T. Greene wrote: >>> It's proper. It's sending a content type of application/JSON not form data. So if you want the value other than the URL param, it would have to be in the DMR and read from the model node >>> >>>>> On Oct 2, 2014, at 6:01 PM, David M. Lloyd wrote: >>>>> >>>>> On 10/02/2014 05:46 PM, Brian Stansberry wrote: >>>>> On 10/1/14, 9:52 AM, Brian Stansberry wrote: >>>>> >>>>> >>>>>> >>>>>> TODOs: >>>>> >>>>>> >>>>>> 5) Make sure POST works well. My assumption is this is lower priority, >>>>>> as the real use cases would likely use a GET. >>>>> >>>>> If you include the useStreamAsResponse as a query param in the URL, as >>>>> with GET, it works. If you do the proper POST thing and encode the query >>>>> param in the request body it doesn't. The DomainApiHandler tries to >>>>> parse the entire request body into a ModelNode and a leading >>>>> useStreamAsResponse& or trailing &useStreamAsResponse fails. >>>>> >>>>> I'm fine with just requiring encoding the param in the URL, even though >>>>> it isn't proper. I don't plan on spending energy near term on parsing it >>>>> out of a POST request body. >>>>> >>>>> If you're curious to try this with my resp-stream branch, this works: >>>>> >>>>> curl --digest -L -D - >>>>> http://localhost:9990/management?useStreamAsResponse --header >>>>> "Content-Type: application/json" -u user:password -d >>>>> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' >>>>> >>>>> This doesn't: >>>>> >>>>> curl --digest -L -D - http://localhost:9990/management --header >>>>> "Content-Type: application/json" -u user:password -d >>>>> '{"operation":"read-attribute","address":[{"subsystem":"logging"}],"name":"server-log","json.pretty":1}' >>>>> -d useStreamAsResponse >>>> >>>> Maybe because the content type isn't multipart/form-data? I think if >>>> you're going to send or receive content alongside the main payload, >>>> you'll have to use a multipart request and/or response (this also >>>> implies some accept-ish header stuff too IIRC). >>>> -- >>>> - DML >>>> _______________________________________________ >>>> 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 >> >> >> -- >> 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 Tue Oct 7 12:21:15 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 07 Oct 2014 11:21:15 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination Message-ID: <543412FB.8060805@redhat.com> If you are assigned a JIRA for WildFly that requires a change to WildFly Core (either a direct fix or a component upgrade), there (obviously) needs to be a WildFly Core release and upgrade into WildFly proper before the change can be completed. But because we're all asynchronous here, coordination is something of a problem. So, to organize things a bit, I've opened https://issues.jboss.org/browse/WFLY-3945 for upgrading WildFly Core to 1.0.0.Alpha9. If you have a WFCORE task or component upgrade that you think should be finished before the upgrade happens, add the corresponding JIRA as a dependency to that issue. If a WFLY task is blocked waiting for the WFCORE upgrade, add that task as a dependent (in other words, add WFLY-3945 as a dependency to that task; you can do it either way though). If the list gets too large, we'll have a discussion about splitting the work between Alpha9 and Alpha10 (or whatever is next). Keeping the work organized around this issue will remove some of the confusion around what needs updating and when, and why. -- - DML From arun.gupta at gmail.com Tue Oct 7 15:50:55 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 7 Oct 2014 12:50:55 -0700 Subject: [wildfly-dev] Deploying JDBC driver to WildFly Message-ID: I was talking to Adam Bien and he is an avid supporter of WildFly and using it in all his projects now. One of his pet peeves is deployment of JDBC driver. He can either bundle it in WEB-INF/lib but prefer to deploy it on the application server itself. Currently he deploys it as a JBoss module but prefer it to be rather simplistic. His suggestion was to define a directory like "standalone/lib/jdbc" and any JAR files copied there should be automatically deployed as module. What is the recommended way to deploy a JDBC driver to WildFly ? Does it necessarily have to be deployed as JBoss module ? If yes, how can this be simplified ? Cheers Arun -- http://blog.arungupta.me http://twitter.com/arungupta From stuart.w.douglas at gmail.com Tue Oct 7 16:07:44 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 08 Oct 2014 07:07:44 +1100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543412FB.8060805@redhat.com> References: <543412FB.8060805@redhat.com> Message-ID: <54344810.8000805@gmail.com> I think that a big problem with this approach is that there is always going to be another task that should be done and another reason to hold the core release by just a few more days. I don't really think that we need this level of process around a Wildfly Core release. I think that we should just be doing these releases fairly frequently, and if some work misses the release then there is always another release coming up in the near future. I think that a JIRA that tracks what is waiting on the next WF core release is a good idea, as it lets us see what is blocked waiting on the next release, however I don't think we should be holding up a core release based on work in the pipeline. Stuart David M. Lloyd wrote: > If you are assigned a JIRA for WildFly that requires a change to WildFly > Core (either a direct fix or a component upgrade), there (obviously) > needs to be a WildFly Core release and upgrade into WildFly proper > before the change can be completed. But because we're all asynchronous > here, coordination is something of a problem. > > So, to organize things a bit, I've opened > https://issues.jboss.org/browse/WFLY-3945 for upgrading WildFly Core to > 1.0.0.Alpha9. > > If you have a WFCORE task or component upgrade that you think should be > finished before the upgrade happens, add the corresponding JIRA as a > dependency to that issue. If a WFLY task is blocked waiting for the > WFCORE upgrade, add that task as a dependent (in other words, add > WFLY-3945 as a dependency to that task; you can do it either way though). > > If the list gets too large, we'll have a discussion about splitting the > work between Alpha9 and Alpha10 (or whatever is next). > > Keeping the work organized around this issue will remove some of the > confusion around what needs updating and when, and why. From brian.stansberry at redhat.com Tue Oct 7 16:31:13 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 07 Oct 2014 15:31:13 -0500 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: References: Message-ID: <54344D91.5040008@redhat.com> You can deploy the driver as a jar, just like a war, ear etc. Then use the deployment name in the driver element of the datasource config. https://docs.jboss.org/author/display/WFLY9/DataSource+configuration This old wiki article is pretty good too: https://developer.jboss.org/wiki/DataSourceConfigurationInAS7 On 10/7/14, 2:50 PM, Arun Gupta wrote: > I was talking to Adam Bien and he is an avid supporter of WildFly and > using it in all his projects now. One of his pet peeves is deployment > of JDBC driver. > > He can either bundle it in WEB-INF/lib but prefer to deploy it on the > application server itself. Currently he deploys it as a JBoss module > but prefer it to be rather simplistic. His suggestion was to define a > directory like "standalone/lib/jdbc" and any JAR files copied there > should be automatically deployed as module. > > What is the recommended way to deploy a JDBC driver to WildFly ? > > Does it necessarily have to be deployed as JBoss module ? If yes, how > can this be simplified ? > > Cheers > Arun > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hpehl at redhat.com Tue Oct 7 16:32:21 2014 From: hpehl at redhat.com (Harald Pehl) Date: Tue, 7 Oct 2014 22:32:21 +0200 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: References: Message-ID: <53517D98-8DBF-43D2-AFD3-208F278905CF@redhat.com> If it's a JDBC 4 compliant driver you can deploy it as regular jar and it will be detected automatically [1]. [1] https://docs.jboss.org/author/display/WFLY8/DataSource+configuration Am 07.10.2014 um 21:50 schrieb Arun Gupta : > I was talking to Adam Bien and he is an avid supporter of WildFly and > using it in all his projects now. One of his pet peeves is deployment > of JDBC driver. > > He can either bundle it in WEB-INF/lib but prefer to deploy it on the > application server itself. Currently he deploys it as a JBoss module > but prefer it to be rather simplistic. His suggestion was to define a > directory like "standalone/lib/jdbc" and any JAR files copied there > should be automatically deployed as module. > > What is the recommended way to deploy a JDBC driver to WildFly ? > > Does it necessarily have to be deployed as JBoss module ? If yes, how > can this be simplified ? > > Cheers > Arun > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev --- Harald Pehl JBoss by Red Hat http://hpehl.info From arun.gupta at gmail.com Tue Oct 7 16:36:50 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 7 Oct 2014 13:36:50 -0700 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: <54344D91.5040008@redhat.com> References: <54344D91.5040008@redhat.com> Message-ID: Cool, I think this is what he was looking for. I've forwarded the information to him and hopefully this will make his life somewhat simpler and create a stickiness with WildFly :) On Tue, Oct 7, 2014 at 1:31 PM, Brian Stansberry wrote: > You can deploy the driver as a jar, just like a war, ear etc. Then use > the deployment name in the driver element of the datasource config. > > https://docs.jboss.org/author/display/WFLY9/DataSource+configuration > > This old wiki article is pretty good too: > > https://developer.jboss.org/wiki/DataSourceConfigurationInAS7 > > On 10/7/14, 2:50 PM, Arun Gupta wrote: >> I was talking to Adam Bien and he is an avid supporter of WildFly and >> using it in all his projects now. One of his pet peeves is deployment >> of JDBC driver. >> >> He can either bundle it in WEB-INF/lib but prefer to deploy it on the >> application server itself. Currently he deploys it as a JBoss module >> but prefer it to be rather simplistic. His suggestion was to define a >> directory like "standalone/lib/jdbc" and any JAR files copied there >> should be automatically deployed as module. >> >> What is the recommended way to deploy a JDBC driver to WildFly ? >> >> Does it necessarily have to be deployed as JBoss module ? If yes, how >> can this be simplified ? >> >> Cheers >> Arun >> > > > -- > 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 -- http://blog.arungupta.me http://twitter.com/arungupta From david.lloyd at redhat.com Tue Oct 7 17:24:14 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 07 Oct 2014 16:24:14 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54344810.8000805@gmail.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> Message-ID: <543459FE.2030402@redhat.com> Yeah that wasn't really my intent, it's more of an advisory thing. The point is to have the data in the issue so that it's always clear what's going on around the release. The dependencies can always be updated to a later release if a core release needs to be done before 100% of its prerequisites are done. On the other hand, if you (or whomever) sees that there's something that is almost ready, you might decide to coordinate with that person. The important thing is to have the information handy. On 10/07/2014 03:07 PM, Stuart Douglas wrote: > I think that a big problem with this approach is that there is always > going to be another task that should be done and another reason to hold > the core release by just a few more days. > > I don't really think that we need this level of process around a Wildfly > Core release. I think that we should just be doing these releases fairly > frequently, and if some work misses the release then there is always > another release coming up in the near future. > > I think that a JIRA that tracks what is waiting on the next WF core > release is a good idea, as it lets us see what is blocked waiting on the > next release, however I don't think we should be holding up a core > release based on work in the pipeline. > > Stuart > > > > David M. Lloyd wrote: >> If you are assigned a JIRA for WildFly that requires a change to WildFly >> Core (either a direct fix or a component upgrade), there (obviously) >> needs to be a WildFly Core release and upgrade into WildFly proper >> before the change can be completed. But because we're all asynchronous >> here, coordination is something of a problem. >> >> So, to organize things a bit, I've opened >> https://issues.jboss.org/browse/WFLY-3945 for upgrading WildFly Core to >> 1.0.0.Alpha9. >> >> If you have a WFCORE task or component upgrade that you think should be >> finished before the upgrade happens, add the corresponding JIRA as a >> dependency to that issue. If a WFLY task is blocked waiting for the >> WFCORE upgrade, add that task as a dependent (in other words, add >> WFLY-3945 as a dependency to that task; you can do it either way though). >> >> If the list gets too large, we'll have a discussion about splitting the >> work between Alpha9 and Alpha10 (or whatever is next). >> >> Keeping the work organized around this issue will remove some of the >> confusion around what needs updating and when, and why. -- - DML From arjan.tijms at gmail.com Tue Oct 7 17:48:11 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 7 Oct 2014 23:48:11 +0200 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: References: <54344D91.5040008@redhat.com> Message-ID: Hi, Just wondering, would it make sense for Arquillian to have (limited) support for deploying/copying things like this JDBC driver, but also things like JACC and JASPIC modules to the application server itself? This is now particularly hard to test, but it's clearly an important use case. Kind regards, Arjan Tijms On Tue, Oct 7, 2014 at 10:36 PM, Arun Gupta wrote: > Cool, I think this is what he was looking for. > > I've forwarded the information to him and hopefully this will make his > life somewhat simpler and create a stickiness with WildFly :) > > On Tue, Oct 7, 2014 at 1:31 PM, Brian Stansberry > wrote: >> You can deploy the driver as a jar, just like a war, ear etc. Then use >> the deployment name in the driver element of the datasource config. >> >> https://docs.jboss.org/author/display/WFLY9/DataSource+configuration >> >> This old wiki article is pretty good too: >> >> https://developer.jboss.org/wiki/DataSourceConfigurationInAS7 >> >> On 10/7/14, 2:50 PM, Arun Gupta wrote: >>> I was talking to Adam Bien and he is an avid supporter of WildFly and >>> using it in all his projects now. One of his pet peeves is deployment >>> of JDBC driver. >>> >>> He can either bundle it in WEB-INF/lib but prefer to deploy it on the >>> application server itself. Currently he deploys it as a JBoss module >>> but prefer it to be rather simplistic. His suggestion was to define a >>> directory like "standalone/lib/jdbc" and any JAR files copied there >>> should be automatically deployed as module. >>> >>> What is the recommended way to deploy a JDBC driver to WildFly ? >>> >>> Does it necessarily have to be deployed as JBoss module ? If yes, how >>> can this be simplified ? >>> >>> Cheers >>> Arun >>> >> >> >> -- >> 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 > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From arun.gupta at gmail.com Tue Oct 7 20:53:08 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Tue, 7 Oct 2014 17:53:08 -0700 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: <54344D91.5040008@redhat.com> References: <54344D91.5040008@redhat.com> Message-ID: Including Adam in the loop and here is what he had to say: -- cut here -- I tried to install either DerbyDB or HSQLDB and they did not had the META-INF/services/java.sql.Driver file. In such case you will have to re-create the jar with the property file. I would expect to just make the JARs available in the CLASSPATH as it is the case in all other application servers, -- cut here -- Suggestions ? Arun On Tue, Oct 7, 2014 at 1:31 PM, Brian Stansberry wrote: > You can deploy the driver as a jar, just like a war, ear etc. Then use > the deployment name in the driver element of the datasource config. > > https://docs.jboss.org/author/display/WFLY9/DataSource+configuration > > This old wiki article is pretty good too: > > https://developer.jboss.org/wiki/DataSourceConfigurationInAS7 > > On 10/7/14, 2:50 PM, Arun Gupta wrote: >> I was talking to Adam Bien and he is an avid supporter of WildFly and >> using it in all his projects now. One of his pet peeves is deployment >> of JDBC driver. >> >> He can either bundle it in WEB-INF/lib but prefer to deploy it on the >> application server itself. Currently he deploys it as a JBoss module >> but prefer it to be rather simplistic. His suggestion was to define a >> directory like "standalone/lib/jdbc" and any JAR files copied there >> should be automatically deployed as module. >> >> What is the recommended way to deploy a JDBC driver to WildFly ? >> >> Does it necessarily have to be deployed as JBoss module ? If yes, how >> can this be simplified ? >> >> Cheers >> Arun >> > > > -- > 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 -- http://blog.arungupta.me http://twitter.com/arungupta From stuart.w.douglas at gmail.com Tue Oct 7 21:46:12 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 08 Oct 2014 12:46:12 +1100 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: References: <54344D91.5040008@redhat.com> Message-ID: <54349764.7090403@gmail.com> I have often though that it would be good to have support in jboss-modules for directory based resource root (i.e. include all jars in a directory). That way we could include a pre-configured module directory that the user can just dump their drivers in, and we could also include a pre-configured global module, to make it easy for a user to expose a library to every deployed application. Stuart Arun Gupta wrote: > Including Adam in the loop and here is what he had to say: > > -- cut here -- > I tried to install either DerbyDB or HSQLDB and they did not had the > META-INF/services/java.sql.Driver file. In such case you will have to > re-create the jar with the property file. > > I would expect to just make the JARs available in the CLASSPATH as it > is the case in all other application servers, > -- cut here -- > > Suggestions ? > > Arun > > On Tue, Oct 7, 2014 at 1:31 PM, Brian Stansberry > wrote: >> You can deploy the driver as a jar, just like a war, ear etc. Then use >> the deployment name in the driver element of the datasource config. >> >> https://docs.jboss.org/author/display/WFLY9/DataSource+configuration >> >> This old wiki article is pretty good too: >> >> https://developer.jboss.org/wiki/DataSourceConfigurationInAS7 >> >> On 10/7/14, 2:50 PM, Arun Gupta wrote: >>> I was talking to Adam Bien and he is an avid supporter of WildFly and >>> using it in all his projects now. One of his pet peeves is deployment >>> of JDBC driver. >>> >>> He can either bundle it in WEB-INF/lib but prefer to deploy it on the >>> application server itself. Currently he deploys it as a JBoss module >>> but prefer it to be rather simplistic. His suggestion was to define a >>> directory like "standalone/lib/jdbc" and any JAR files copied there >>> should be automatically deployed as module. >>> >>> What is the recommended way to deploy a JDBC driver to WildFly ? >>> >>> Does it necessarily have to be deployed as JBoss module ? If yes, how >>> can this be simplified ? >>> >>> Cheers >>> Arun >>> >> >> -- >> 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 hbraun at redhat.com Wed Oct 8 02:21:35 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 8 Oct 2014 08:21:35 +0200 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54344810.8000805@gmail.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> Message-ID: <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> Does it help to put Core on a time boxed schedule? On 07 Oct 2014, at 22:07, Stuart Douglas wrote: > I don't really think that we need this level of process around a Wildfly > Core release. I think that we should just be doing these releases fairly > frequently, and if some work misses the release then there is always > another release coming up in the near future. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141008/16e525e9/attachment.html From hbraun at redhat.com Wed Oct 8 02:26:00 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 8 Oct 2014 08:26:00 +0200 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: <54349764.7090403@gmail.com> References: <54344D91.5040008@redhat.com> <54349764.7090403@gmail.com> Message-ID: <28642F47-C400-4E7F-A0AC-FDFB25087AF7@redhat.com> +1 On 08 Oct 2014, at 03:46, Stuart Douglas wrote: > That way we could include a pre-configured module directory that the > user can just dump their drivers in, and we could also include a > pre-configured global module, to make it easy for a user to expose a > library to every deployed application. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141008/007b1442/attachment-0001.html From darran.lofthouse at jboss.com Wed Oct 8 06:31:49 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 08 Oct 2014 11:31:49 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> Message-ID: <54351295.6080303@jboss.com> I don't know if it needs to be a short timebox say weekly or better if on-demand e.g. if an engineer is working on an issue in both core and wildfly they request a core release and upgrade to continue their work. At the same time I think we do need the Jiras as David suggests to track what we actually needs, unfortunately this does create some additional maintenance as these need updating after each release. On 08/10/14 07:21, Heiko Braun wrote: > Does it help to put Core on a time boxed schedule? > > On 07 Oct 2014, at 22:07, Stuart Douglas > wrote: > >> I don't really think that we need this level of process around a Wildfly >> Core release. I think that we should just be doing these releases fairly >> frequently, and if some work misses the release then there is always >> another release coming up in the near future. > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From tomaz.cerar at gmail.com Wed Oct 8 08:24:33 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 8 Oct 2014 14:24:33 +0200 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54351295.6080303@jboss.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> Message-ID: I had some discussions with Jason on how we could automate time boxed releases by just having a button in CI that would perform it. So we at least have a bit of human interaction. We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... -- tomaz On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > I don't know if it needs to be a short timebox say weekly or better if > on-demand e.g. if an engineer is working on an issue in both core and > wildfly they request a core release and upgrade to continue their work. > > At the same time I think we do need the Jiras as David suggests to track > what we actually needs, unfortunately this does create some additional > maintenance as these need updating after each release. > > On 08/10/14 07:21, Heiko Braun wrote: > > Does it help to put Core on a time boxed schedule? > > > > On 07 Oct 2014, at 22:07, Stuart Douglas > > wrote: > > > >> I don't really think that we need this level of process around a Wildfly > >> Core release. I think that we should just be doing these releases fairly > >> frequently, and if some work misses the release then there is always > >> another release coming up in the near future. > > > > > > > > _______________________________________________ > > 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/20141008/387575e3/attachment.html From jesper.pedersen at redhat.com Wed Oct 8 08:37:03 2014 From: jesper.pedersen at redhat.com (Jesper Pedersen) Date: Wed, 08 Oct 2014 08:37:03 -0400 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: References: Message-ID: <54352FEF.9030509@redhat.com> On 10/07/2014 03:50 PM, Arun Gupta wrote: > > What is the recommended way to deploy a JDBC driver to WildFly ? > Deploying as a module is the recommended way for a number of reasons, * JDBC driver is split into multiple JARs that needs to be considered as one unit * JDBC driver needs to be linked with already deployed modules * Multiple versions of the 'same' JDBC driver for a vendor (yes, you can rename when using deployments/) * Native code integration So, while having the option to deploy a JDBC driver in a simple way is good, it doesn't cover all the cases that are needed in enterprise deployments. Best regards, Jesper From darran.lofthouse at jboss.com Wed Oct 8 08:38:57 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 08 Oct 2014 13:38:57 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> Message-ID: <54353061.7090109@jboss.com> How about a timestamp instead of an index, at a glance you can see how old the current core actually is. On 08/10/14 13:24, Toma? Cerar wrote: > I had some discussions with Jason on how we could automate > time boxed releases by just having a button in CI that would perform it. > So we at least have a bit of human interaction. > > We could also have it done automatically by CI every week on schedule > that shouldn't be a big deal to do. > If we do that we should have "indexed" build versions like > 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... > > -- > tomaz > > On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse > > wrote: > > I don't know if it needs to be a short timebox say weekly or better if > on-demand e.g. if an engineer is working on an issue in both core and > wildfly they request a core release and upgrade to continue their work. > > At the same time I think we do need the Jiras as David suggests to track > what we actually needs, unfortunately this does create some additional > maintenance as these need updating after each release. > > On 08/10/14 07:21, Heiko Braun wrote: > > Does it help to put Core on a time boxed schedule? > > > > On 07 Oct 2014, at 22:07, Stuart Douglas > > >> wrote: > > > >> I don't really think that we need this level of process around a Wildfly > >> Core release. I think that we should just be doing these releases fairly > >> frequently, and if some work misses the release then there is always > >> another release coming up in the near future. > > > > > > > > _______________________________________________ > > 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 kabir.khan at jboss.com Wed Oct 8 08:40:41 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 8 Oct 2014 13:40:41 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> Message-ID: <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P On 8 Oct 2014, at 13:24, Toma? Cerar wrote: > I had some discussions with Jason on how we could automate > time boxed releases by just having a button in CI that would perform it. > So we at least have a bit of human interaction. > > We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. > If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... > > -- > tomaz > > On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse wrote: > I don't know if it needs to be a short timebox say weekly or better if > on-demand e.g. if an engineer is working on an issue in both core and > wildfly they request a core release and upgrade to continue their work. > > At the same time I think we do need the Jiras as David suggests to track > what we actually needs, unfortunately this does create some additional > maintenance as these need updating after each release. > > On 08/10/14 07:21, Heiko Braun wrote: > > Does it help to put Core on a time boxed schedule? > > > > On 07 Oct 2014, at 22:07, Stuart Douglas > > wrote: > > > >> I don't really think that we need this level of process around a Wildfly > >> Core release. I think that we should just be doing these releases fairly > >> frequently, and if some work misses the release then there is always > >> another release coming up in the near future. > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Wed Oct 8 08:41:53 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 8 Oct 2014 13:41:53 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> Message-ID: <0CE3CC1A-EE77-4DB6-A29B-E4CB5CEFD6DC@jboss.com> Also, it makes it easier to e.g. synchronise for the rare cases when incompatible changes are made to core requiring wildfly fixes. On 8 Oct 2014, at 13:40, Kabir Khan wrote: > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P > On 8 Oct 2014, at 13:24, Toma? Cerar wrote: > >> I had some discussions with Jason on how we could automate >> time boxed releases by just having a button in CI that would perform it. >> So we at least have a bit of human interaction. >> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >> >> -- >> tomaz >> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse wrote: >> I don't know if it needs to be a short timebox say weekly or better if >> on-demand e.g. if an engineer is working on an issue in both core and >> wildfly they request a core release and upgrade to continue their work. >> >> At the same time I think we do need the Jiras as David suggests to track >> what we actually needs, unfortunately this does create some additional >> maintenance as these need updating after each release. >> >> On 08/10/14 07:21, Heiko Braun wrote: >>> Does it help to put Core on a time boxed schedule? >>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >> > wrote: >>> >>>> I don't really think that we need this level of process around a Wildfly >>>> Core release. I think that we should just be doing these releases fairly >>>> frequently, and if some work misses the release then there is always >>>> another release coming up in the near future. >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Wed Oct 8 08:43:20 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 08 Oct 2014 13:43:20 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> Message-ID: <54353168.9010709@jboss.com> Maybe something with labels, if a PR is labelled a blocker no releases are performed until it is in? On 08/10/14 13:40, Kabir Khan wrote: > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P > On 8 Oct 2014, at 13:24, Toma? Cerar wrote: > >> I had some discussions with Jason on how we could automate >> time boxed releases by just having a button in CI that would perform it. >> So we at least have a bit of human interaction. >> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >> >> -- >> tomaz >> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse wrote: >> I don't know if it needs to be a short timebox say weekly or better if >> on-demand e.g. if an engineer is working on an issue in both core and >> wildfly they request a core release and upgrade to continue their work. >> >> At the same time I think we do need the Jiras as David suggests to track >> what we actually needs, unfortunately this does create some additional >> maintenance as these need updating after each release. >> >> On 08/10/14 07:21, Heiko Braun wrote: >>> Does it help to put Core on a time boxed schedule? >>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >> > wrote: >>> >>>> I don't really think that we need this level of process around a Wildfly >>>> Core release. I think that we should just be doing these releases fairly >>>> frequently, and if some work misses the release then there is always >>>> another release coming up in the near future. >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Wed Oct 8 10:57:22 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 08 Oct 2014 09:57:22 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> Message-ID: <543550D2.3040407@redhat.com> Just telling people "hey I'm releasing core in a day or two" is already 10x better than the current status quo. On 10/08/2014 07:40 AM, Kabir Khan wrote: > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P > On 8 Oct 2014, at 13:24, Toma? Cerar wrote: > >> I had some discussions with Jason on how we could automate >> time boxed releases by just having a button in CI that would perform it. >> So we at least have a bit of human interaction. >> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >> >> -- >> tomaz >> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse wrote: >> I don't know if it needs to be a short timebox say weekly or better if >> on-demand e.g. if an engineer is working on an issue in both core and >> wildfly they request a core release and upgrade to continue their work. >> >> At the same time I think we do need the Jiras as David suggests to track >> what we actually needs, unfortunately this does create some additional >> maintenance as these need updating after each release. >> >> On 08/10/14 07:21, Heiko Braun wrote: >>> Does it help to put Core on a time boxed schedule? >>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >> > wrote: >>> >>>> I don't really think that we need this level of process around a Wildfly >>>> Core release. I think that we should just be doing these releases fairly >>>> frequently, and if some work misses the release then there is always >>>> another release coming up in the near future. >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From tomaz.cerar at gmail.com Wed Oct 8 11:00:23 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 8 Oct 2014 17:00:23 +0200 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543550D2.3040407@redhat.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> Message-ID: that still doesnt solve the problem on "when" next release is. as people that need to do work across both repos need to know this info. Current state is just too unknown and annoyng if you need to do something in core and then also in full to make it work. not to even add to the mix that your PR *needs* to break something in full, at least until your PR for full is also merged. On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd wrote: > Just telling people "hey I'm releasing core in a day or two" is already > 10x better than the current status quo. > > On 10/08/2014 07:40 AM, Kabir Khan wrote: > > I think I prefer the 'human interaction' one best. What if the automatic > one does the release, just as someone is attempting to merge a bunch of PRs > which should be in the release? Although that might be a corner case :-P > > On 8 Oct 2014, at 13:24, Toma? Cerar wrote: > > > >> I had some discussions with Jason on how we could automate > >> time boxed releases by just having a button in CI that would perform it. > >> So we at least have a bit of human interaction. > >> > >> We could also have it done automatically by CI every week on schedule > that shouldn't be a big deal to do. > >> If we do that we should have "indexed" build versions like > 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... > >> > >> -- > >> tomaz > >> > >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse < > darran.lofthouse at jboss.com> wrote: > >> I don't know if it needs to be a short timebox say weekly or better if > >> on-demand e.g. if an engineer is working on an issue in both core and > >> wildfly they request a core release and upgrade to continue their work. > >> > >> At the same time I think we do need the Jiras as David suggests to track > >> what we actually needs, unfortunately this does create some additional > >> maintenance as these need updating after each release. > >> > >> On 08/10/14 07:21, Heiko Braun wrote: > >>> Does it help to put Core on a time boxed schedule? > >>> > >>> On 07 Oct 2014, at 22:07, Stuart Douglas >>> > wrote: > >>> > >>>> I don't really think that we need this level of process around a > Wildfly > >>>> Core release. I think that we should just be doing these releases > fairly > >>>> frequently, and if some work misses the release then there is always > >>>> another release coming up in the near future. > >>> > >>> > >>> > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > - DML > _______________________________________________ > 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/20141008/0ab09a5f/attachment.html From david.lloyd at redhat.com Wed Oct 8 11:01:23 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 08 Oct 2014 10:01:23 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> Message-ID: <543551C3.2000908@redhat.com> I'll take whatever I can get. :-) On 10/08/2014 10:00 AM, Toma? Cerar wrote: > that still doesnt solve the problem on "when" next release is. > > as people that need to do work across both repos need to know this info. > Current state is just too unknown and annoyng if you need to do > something in core and then also in full to make it work. > not to even add to the mix that your PR *needs* to break something in > full, at least until your PR for full is also merged. > > > > On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd > wrote: > > Just telling people "hey I'm releasing core in a day or two" is already > 10x better than the current status quo. > > On 10/08/2014 07:40 AM, Kabir Khan wrote: > > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P > > On 8 Oct 2014, at 13:24, Toma? Cerar > wrote: > > > >> I had some discussions with Jason on how we could automate > >> time boxed releases by just having a button in CI that would perform it. > >> So we at least have a bit of human interaction. > >> > >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. > >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... > >> > >> -- > >> tomaz > >> > >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse > wrote: > >> I don't know if it needs to be a short timebox say weekly or better if > >> on-demand e.g. if an engineer is working on an issue in both core and > >> wildfly they request a core release and upgrade to continue their work. > >> > >> At the same time I think we do need the Jiras as David suggests to track > >> what we actually needs, unfortunately this does create some additional > >> maintenance as these need updating after each release. > >> > >> On 08/10/14 07:21, Heiko Braun wrote: > >>> Does it help to put Core on a time boxed schedule? > >>> > >>> On 07 Oct 2014, at 22:07, Stuart Douglas > >>> >> wrote: > >>> > >>>> I don't really think that we need this level of process around a Wildfly > >>>> Core release. I think that we should just be doing these releases fairly > >>>> frequently, and if some work misses the release then there is always > >>>> another release coming up in the near future. > >>> > >>> > >>> > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>>wildfly-dev at lists.jboss.org > >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > >> _______________________________________________ > >> wildfly-dev mailing list > >>wildfly-dev at lists.jboss.org > >>https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >>wildfly-dev at lists.jboss.org > >>https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > > wildfly-dev mailing list > >wildfly-dev at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- - DML From arun.gupta at gmail.com Wed Oct 8 15:00:20 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 8 Oct 2014 12:00:20 -0700 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: <54352FEF.9030509@redhat.com> References: <54352FEF.9030509@redhat.com> Message-ID: I think providing a tool or CLI or directory that covers majority of the cases would be really useful. Arun On Wed, Oct 8, 2014 at 5:37 AM, Jesper Pedersen wrote: > On 10/07/2014 03:50 PM, Arun Gupta wrote: >> >> >> What is the recommended way to deploy a JDBC driver to WildFly ? >> > > Deploying as a module is the recommended way for a number of reasons, > > * JDBC driver is split into multiple JARs that needs to be considered as one > unit > * JDBC driver needs to be linked with already deployed modules > * Multiple versions of the 'same' JDBC driver for a vendor (yes, you can > rename when using deployments/) > * Native code integration > > So, while having the option to deploy a JDBC driver in a simple way is good, > it doesn't cover all the cases that are needed in enterprise deployments. > > Best regards, > Jesper > -- http://blog.arungupta.me http://twitter.com/arungupta From smarlow at redhat.com Wed Oct 8 15:21:18 2014 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 08 Oct 2014 15:21:18 -0400 Subject: [wildfly-dev] Deploying JDBC driver to WildFly In-Reply-To: References: <54352FEF.9030509@redhat.com> Message-ID: <54358EAE.5030407@redhat.com> We should probably have a wizard or tool for adding persistence providers also. That is easier with WildFly 8.x but could be easier. I think that the EAP installer might have a wizard for adding JDBC drivers, so that is always an option for users. On 10/08/2014 03:00 PM, Arun Gupta wrote: > I think providing a tool or CLI or directory that covers majority of > the cases would be really useful. > > Arun > > On Wed, Oct 8, 2014 at 5:37 AM, Jesper Pedersen > wrote: >> On 10/07/2014 03:50 PM, Arun Gupta wrote: >>> >>> >>> What is the recommended way to deploy a JDBC driver to WildFly ? >>> >> >> Deploying as a module is the recommended way for a number of reasons, >> >> * JDBC driver is split into multiple JARs that needs to be considered as one >> unit >> * JDBC driver needs to be linked with already deployed modules >> * Multiple versions of the 'same' JDBC driver for a vendor (yes, you can >> rename when using deployments/) >> * Native code integration >> >> So, while having the option to deploy a JDBC driver in a simple way is good, >> it doesn't cover all the cases that are needed in enterprise deployments. >> >> Best regards, >> Jesper >> > > > From stuart.w.douglas at gmail.com Wed Oct 8 16:26:32 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 09 Oct 2014 07:26:32 +1100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543551C3.2000908@redhat.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> <543551C3.2000908@redhat.com> Message-ID: <54359DF8.7030707@gmail.com> I think the best way to deal with this is just a time boxed release, say every Friday afternoon. That way there is no surprises, and if a PR is not ready then it can go into next weeks release. I don't think automation is a good idea, there are to many things that can go wrong. Stuart David M. Lloyd wrote: > I'll take whatever I can get. :-) > > On 10/08/2014 10:00 AM, Toma? Cerar wrote: >> that still doesnt solve the problem on "when" next release is. >> >> as people that need to do work across both repos need to know this info. >> Current state is just too unknown and annoyng if you need to do >> something in core and then also in full to make it work. >> not to even add to the mix that your PR *needs* to break something in >> full, at least until your PR for full is also merged. >> >> >> >> On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd> > wrote: >> >> Just telling people "hey I'm releasing core in a day or two" is already >> 10x better than the current status quo. >> >> On 10/08/2014 07:40 AM, Kabir Khan wrote: >> > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P >> > On 8 Oct 2014, at 13:24, Toma? Cerar> wrote: >> > >> >> I had some discussions with Jason on how we could automate >> >> time boxed releases by just having a button in CI that would perform it. >> >> So we at least have a bit of human interaction. >> >> >> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >> >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >> >> >> >> -- >> >> tomaz >> >> >> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse> wrote: >> >> I don't know if it needs to be a short timebox say weekly or better if >> >> on-demand e.g. if an engineer is working on an issue in both core and >> >> wildfly they request a core release and upgrade to continue their work. >> >> >> >> At the same time I think we do need the Jiras as David suggests to track >> >> what we actually needs, unfortunately this does create some additional >> >> maintenance as these need updating after each release. >> >> >> >> On 08/10/14 07:21, Heiko Braun wrote: >> >>> Does it help to put Core on a time boxed schedule? >> >>> >> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >> >>> >> wrote: >> >>> >> >>>> I don't really think that we need this level of process around a Wildfly >> >>>> Core release. I think that we should just be doing these releases fairly >> >>>> frequently, and if some work misses the release then there is always >> >>>> another release coming up in the near future. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> wildfly-dev mailing list >> >>>wildfly-dev at lists.jboss.org >> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >>> >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >>wildfly-dev at lists.jboss.org >> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >>wildfly-dev at lists.jboss.org >> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> >wildfly-dev at lists.jboss.org >> >https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> > From david.lloyd at redhat.com Wed Oct 8 16:44:22 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 08 Oct 2014 15:44:22 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54359DF8.7030707@gmail.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> <543551C3.2000908@redhat.com> <54359DF8.7030707@gmail.com> Message-ID: <5435A226.3070906@redhat.com> I agree, the amount of effort required getting automation working *correctly* is going to exceed the amount of work it would save. Doing releases by hand is easy enough. On 10/08/2014 03:26 PM, Stuart Douglas wrote: > I think the best way to deal with this is just a time boxed release, say > every Friday afternoon. That way there is no surprises, and if a PR is > not ready then it can go into next weeks release. > > I don't think automation is a good idea, there are to many things that > can go wrong. > > Stuart > > David M. Lloyd wrote: >> I'll take whatever I can get. :-) >> >> On 10/08/2014 10:00 AM, Toma? Cerar wrote: >>> that still doesnt solve the problem on "when" next release is. >>> >>> as people that need to do work across both repos need to know this info. >>> Current state is just too unknown and annoyng if you need to do >>> something in core and then also in full to make it work. >>> not to even add to the mix that your PR *needs* to break something in >>> full, at least until your PR for full is also merged. >>> >>> >>> >>> On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd>> > wrote: >>> >>> Just telling people "hey I'm releasing core in a day or two" is >>> already >>> 10x better than the current status quo. >>> >>> On 10/08/2014 07:40 AM, Kabir Khan wrote: >>> > I think I prefer the 'human interaction' one best. What if >>> the automatic one does the release, just as someone is attempting to >>> merge a bunch of PRs which should be in the release? Although that >>> might be a corner case :-P >>> > On 8 Oct 2014, at 13:24, Toma? >>> Cerar> wrote: >>> > >>> >> I had some discussions with Jason on how we could automate >>> >> time boxed releases by just having a button in CI that would >>> perform it. >>> >> So we at least have a bit of human interaction. >>> >> >>> >> We could also have it done automatically by CI every week on >>> schedule that shouldn't be a big deal to do. >>> >> If we do that we should have "indexed" build versions like >>> 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >>> >> >>> >> -- >>> >> tomaz >>> >> >>> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran >>> Lofthouse> >>> wrote: >>> >> I don't know if it needs to be a short timebox say weekly or >>> better if >>> >> on-demand e.g. if an engineer is working on an issue in both >>> core and >>> >> wildfly they request a core release and upgrade to continue >>> their work. >>> >> >>> >> At the same time I think we do need the Jiras as David >>> suggests to track >>> >> what we actually needs, unfortunately this does create some >>> additional >>> >> maintenance as these need updating after each release. >>> >> >>> >> On 08/10/14 07:21, Heiko Braun wrote: >>> >>> Does it help to put Core on a time boxed schedule? >>> >>> >>> >>> On 07 Oct 2014, at 22:07, Stuart >>> Douglas >>> >>> >>> >> >>> wrote: >>> >>> >>> >>>> I don't really think that we need this level of process >>> around a Wildfly >>> >>>> Core release. I think that we should just be doing these >>> releases fairly >>> >>>> frequently, and if some work misses the release then there >>> is always >>> >>>> another release coming up in the near future. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> wildfly-dev mailing list >>> >>>wildfly-dev at lists.jboss.org >>> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >> _______________________________________________ >>> >> wildfly-dev mailing list >>> >>wildfly-dev at lists.jboss.org >>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >>> >> _______________________________________________ >>> >> wildfly-dev mailing list >>> >>wildfly-dev at lists.jboss.org >>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > >>> > >>> > _______________________________________________ >>> > wildfly-dev mailing list >>> >wildfly-dev at lists.jboss.org >>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > >>> >>> -- >>> - DML >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >> -- - DML From tomaz.cerar at gmail.com Wed Oct 8 17:24:34 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 8 Oct 2014 23:24:34 +0200 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <5435A226.3070906@redhat.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> <543551C3.2000908@redhat.com> <54359DF8.7030707@gmail.com> <5435A226.3070906@redhat.com> Message-ID: On Wed, Oct 8, 2014 at 10:44 PM, David M. Lloyd wrote: > I agree, the amount of effort required getting automation working > *correctly* is going to exceed the amount of work it would save. not really agreeing on this one, as long as maven release plugin works (and it does) this is matter of invoking 3 maven operations. which can be done by anyone with necessary permissions. If release for whatever reason cannot be done that simple, that is another problem that needs to be addressed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141008/3ca407b1/attachment.html From stuart.w.douglas at gmail.com Wed Oct 8 17:57:03 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 09 Oct 2014 08:57:03 +1100 Subject: [wildfly-dev] Undertow statistics In-Reply-To: References: Message-ID: <5435B32F.8060805@gmail.com> This should be done once this PR is merged: https://github.com/wildfly/wildfly/pull/6792 Note that there is a bug in the current version of Undertow where request and response bytes are not counted correctly due to a typo, this will be fixed in the next Undertow release. Stuart Heiko Braun wrote: > I am looking for some undertow metrics, like HTTP request/error rates, etc. I was expecting them to be exposed alongside with the listeners, but cannot find any. Is this missing or am I looking at the wrong resources? > > /Heiko > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From hbraun at redhat.com Thu Oct 9 04:17:14 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 9 Oct 2014 10:17:14 +0200 Subject: [wildfly-dev] Undertow statistics In-Reply-To: <5435B32F.8060805@gmail.com> References: <5435B32F.8060805@gmail.com> Message-ID: <4FA60921-F0EE-45CB-B1CE-7431337D37B0@redhat.com> Thanks Stuart. On 08 Oct 2014, at 23:57, Stuart Douglas wrote: > This should be done once this PR is merged: > > https://github.com/wildfly/wildfly/pull/6792 > > Note that there is a bug in the current version of Undertow where request and response bytes are not counted correctly due to a typo, this will be fixed in the next Undertow release. > > Stuart > > Heiko Braun wrote: >> I am looking for some undertow metrics, like HTTP request/error rates, etc. I was expecting them to be exposed alongside with the listeners, but cannot find any. Is this missing or am I looking at the wrong resources? >> >> /Heiko >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From rory.odonnell at oracle.com Thu Oct 9 05:16:29 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Thu, 09 Oct 2014 10:16:29 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b33 and JDK 8u40 b09 are available on java.net Message-ID: <5436526D.9060409@oracle.com> Hi Guys, Early Access build for JDK 9 b33 is available on java.net, summary of changes are listed here Early Access build for JDK 8u40 b09 is available on java.net, summary of changes are listed here. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141009/29823319/attachment.html From emmanuel at hibernate.org Thu Oct 9 07:27:39 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 9 Oct 2014 14:27:39 +0300 Subject: [wildfly-dev] Deliver 3rd party subsystem to customers? In-Reply-To: <130544E0-64E1-4A18-B552-F0405146CF8D@redhat.com> References: <43C4D1A3-7256-4436-A093-A5B321C1DC06@redhat.com> <054697E9-9395-466F-9BD1-EFBD58EB0ED0@redhat.com> <54298BFB.2040309@redhat.com> <130544E0-64E1-4A18-B552-F0405146CF8D@redhat.com> Message-ID: <20141009112739.GC5052@hibernate.org> I'm interested in that kind of ability as well. Is there a wiki describing the what and how I could lurke and contribute on the use cases side? Emmanuel On Mon 2014-09-29 11:56, Jason Greene wrote: > Yeah this is a key goal of features. > > You can do something like "feature install org.blah.feature?, and it fetches it from maven and installs it. > > On Sep 29, 2014, at 11:42 AM, Brian Stansberry wrote: > > > Agreed. I see feature-packs as the best solution to this kind of thing. > > > > CLI archives are another possibility, with the archive bundling the > > module and then the script executes to install it and make needed mods, > > but my instinct is the feature-pack stuff will end up being a better > > approach. > > > > On 9/29/14, 11:30 AM, Heiko Braun wrote: > >> I think the recently added feature packs work that way. Stuart wrote about that last week: http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002919.html > >> > >> > >> > >> > >> > >> > >>> Am 29.09.2014 um 13:36 schrieb "Heiko W.Rupp" : > >>> > >>> Hey, > >>> > >>> suppose I am writing a subsystem for WildFly, that I can or want not add to the generic WildFly codebase (e.g. because it is not open source or because WildFly team would consider it too special for general consumption). > >>> > >>> Is there a way to package that up in a .zip or any other format (in the good 'ol days we used .shar files :-) > >>> to deliver such a subsystem with its module but also the xsl to modify standalone.xml (or similar)? > >>> > >>> If not (yet), would it make sense for WildFly to reconsider allowing to provide e.g. > >>> * ext.xml > >>> * subsystem.xml > >>> * ports.xml > >>> > >>> that will get merged / added to standalone.xml when the module is loaded for the very first time > >>> (like when the module.jar is also indexed for the first time). > >>> > >>> Thanks > >>> Heiko > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > -- > > 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 > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tsegismo at redhat.com Thu Oct 9 08:47:30 2014 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 09 Oct 2014 14:47:30 +0200 Subject: [wildfly-dev] Management: datasource "enable" operation and "allow-resource-service-restart" operation header Message-ID: <543683E2.8030506@redhat.com> Hi everyone, I understand the difference between calling the "disable" operation on a datasource with the "allow-resource-service-restart" operation header set to true and set to false. I'm wondering if it has any impact on the "enable" operation. I assume that when you enable a datasource, well, you're starting the service so this operation header is useless. Am I wrong? Thanks, Thomas From brian.stansberry at redhat.com Thu Oct 9 08:52:50 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 09 Oct 2014 07:52:50 -0500 Subject: [wildfly-dev] Management: datasource "enable" operation and "allow-resource-service-restart" operation header In-Reply-To: <543683E2.8030506@redhat.com> References: <543683E2.8030506@redhat.com> Message-ID: <54368522.9000705@redhat.com> On 10/9/14, 7:47 AM, Thomas Segismont wrote: > Hi everyone, > > I understand the difference between calling the "disable" operation on a > datasource with the "allow-resource-service-restart" operation header > set to true and set to false. > > I'm wondering if it has any impact on the "enable" operation. I assume > that when you enable a datasource, well, you're starting the service so > this operation header is useless. > > Am I wrong? > No, you are correct. > Thanks, > Thomas > _______________________________________________ > 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 darran.lofthouse at jboss.com Thu Oct 9 08:55:49 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 09 Oct 2014 13:55:49 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54359DF8.7030707@gmail.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> <543551C3.2000908@redhat.com> <54359DF8.7030707@gmail.com> Message-ID: <543685D5.4040006@jboss.com> Could we make an agreement that all PRs submitted by say Thursday afternoon that are ready to be merged are merged before the tag is created. Not saying that Friday's PRs can't be merged just trying to engineers some predictability when they are working on issues that affect both repos. Regards, Darran Lofthouse. On 08/10/14 21:26, Stuart Douglas wrote: > I think the best way to deal with this is just a time boxed release, say > every Friday afternoon. That way there is no surprises, and if a PR is > not ready then it can go into next weeks release. > > I don't think automation is a good idea, there are to many things that > can go wrong. > > Stuart > > David M. Lloyd wrote: >> I'll take whatever I can get. :-) >> >> On 10/08/2014 10:00 AM, Toma? Cerar wrote: >>> that still doesnt solve the problem on "when" next release is. >>> >>> as people that need to do work across both repos need to know this info. >>> Current state is just too unknown and annoyng if you need to do >>> something in core and then also in full to make it work. >>> not to even add to the mix that your PR *needs* to break something in >>> full, at least until your PR for full is also merged. >>> >>> >>> >>> On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd>> > wrote: >>> >>> Just telling people "hey I'm releasing core in a day or two" is already >>> 10x better than the current status quo. >>> >>> On 10/08/2014 07:40 AM, Kabir Khan wrote: >>> > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P >>> > On 8 Oct 2014, at 13:24, Toma? Cerar> wrote: >>> > >>> >> I had some discussions with Jason on how we could automate >>> >> time boxed releases by just having a button in CI that would perform it. >>> >> So we at least have a bit of human interaction. >>> >> >>> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >>> >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >>> >> >>> >> -- >>> >> tomaz >>> >> >>> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse> wrote: >>> >> I don't know if it needs to be a short timebox say weekly or better if >>> >> on-demand e.g. if an engineer is working on an issue in both core and >>> >> wildfly they request a core release and upgrade to continue their work. >>> >> >>> >> At the same time I think we do need the Jiras as David suggests to track >>> >> what we actually needs, unfortunately this does create some additional >>> >> maintenance as these need updating after each release. >>> >> >>> >> On 08/10/14 07:21, Heiko Braun wrote: >>> >>> Does it help to put Core on a time boxed schedule? >>> >>> >>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >>> >>> >> wrote: >>> >>> >>> >>>> I don't really think that we need this level of process around a Wildfly >>> >>>> Core release. I think that we should just be doing these releases fairly >>> >>>> frequently, and if some work misses the release then there is always >>> >>>> another release coming up in the near future. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> wildfly-dev mailing list >>> >>>wildfly-dev at lists.jboss.org >>> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >> _______________________________________________ >>> >> wildfly-dev mailing list >>> >>wildfly-dev at lists.jboss.org >>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >>> >> _______________________________________________ >>> >> wildfly-dev mailing list >>> >>wildfly-dev at lists.jboss.org >>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > >>> > >>> > _______________________________________________ >>> > wildfly-dev mailing list >>> >wildfly-dev at lists.jboss.org >>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > >>> >>> -- >>> - DML >>> _______________________________________________ >>> 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 tsegismo at redhat.com Thu Oct 9 09:11:13 2014 From: tsegismo at redhat.com (Thomas Segismont) Date: Thu, 09 Oct 2014 15:11:13 +0200 Subject: [wildfly-dev] Management: datasource "enable" operation and "allow-resource-service-restart" operation header In-Reply-To: <54368522.9000705@redhat.com> References: <543683E2.8030506@redhat.com> <54368522.9000705@redhat.com> Message-ID: <54368971.60706@redhat.com> Le 09/10/2014 14:52, Brian Stansberry a ?crit : > On 10/9/14, 7:47 AM, Thomas Segismont wrote: >> Hi everyone, >> >> I understand the difference between calling the "disable" operation on a >> datasource with the "allow-resource-service-restart" operation header >> set to true and set to false. >> >> I'm wondering if it has any impact on the "enable" operation. I assume >> that when you enable a datasource, well, you're starting the service so >> this operation header is useless. >> >> Am I wrong? >> > > No, you are correct. Thank you Brian! From brian.stansberry at redhat.com Thu Oct 9 09:25:56 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 09 Oct 2014 08:25:56 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543685D5.4040006@jboss.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> <543551C3.2000908@redhat.com> <54359DF8.7030707@gmail.com> <543685D5.4040006@jboss.com> Message-ID: <54368CE4.1010901@redhat.com> On 10/9/14, 7:55 AM, Darran Lofthouse wrote: > Could we make an agreement that all PRs submitted by say Thursday > afternoon that are ready to be merged are merged before the tag is created. > Given the "ready to be merged" bit, sure, fine with me. I'm not willing to commit to people to get things reviewed and tested on a weekly deadline, but if things are already reviewed and tested I have no problem promising to merge them. I'm just one of the players here, unless I'm nominated as the person who does the weekly release, in which case my promise matters more. But I volunteer to do the release if Jason wants that. > Not saying that Friday's PRs can't be merged just trying to engineers > some predictability when they are working on issues that affect both repos. > > Regards, > Darran Lofthouse. > > > On 08/10/14 21:26, Stuart Douglas wrote: >> I think the best way to deal with this is just a time boxed release, say >> every Friday afternoon. That way there is no surprises, and if a PR is >> not ready then it can go into next weeks release. >> >> I don't think automation is a good idea, there are to many things that >> can go wrong. >> >> Stuart >> >> David M. Lloyd wrote: >>> I'll take whatever I can get. :-) >>> >>> On 10/08/2014 10:00 AM, Toma? Cerar wrote: >>>> that still doesnt solve the problem on "when" next release is. >>>> >>>> as people that need to do work across both repos need to know this info. >>>> Current state is just too unknown and annoyng if you need to do >>>> something in core and then also in full to make it work. >>>> not to even add to the mix that your PR *needs* to break something in >>>> full, at least until your PR for full is also merged. >>>> >>>> >>>> >>>> On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd>>> > wrote: >>>> >>>> Just telling people "hey I'm releasing core in a day or two" is already >>>> 10x better than the current status quo. >>>> >>>> On 10/08/2014 07:40 AM, Kabir Khan wrote: >>>> > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P >>>> > On 8 Oct 2014, at 13:24, Toma? Cerar> wrote: >>>> > >>>> >> I had some discussions with Jason on how we could automate >>>> >> time boxed releases by just having a button in CI that would perform it. >>>> >> So we at least have a bit of human interaction. >>>> >> >>>> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >>>> >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >>>> >> >>>> >> -- >>>> >> tomaz >>>> >> >>>> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse> wrote: >>>> >> I don't know if it needs to be a short timebox say weekly or better if >>>> >> on-demand e.g. if an engineer is working on an issue in both core and >>>> >> wildfly they request a core release and upgrade to continue their work. >>>> >> >>>> >> At the same time I think we do need the Jiras as David suggests to track >>>> >> what we actually needs, unfortunately this does create some additional >>>> >> maintenance as these need updating after each release. >>>> >> >>>> >> On 08/10/14 07:21, Heiko Braun wrote: >>>> >>> Does it help to put Core on a time boxed schedule? >>>> >>> >>>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >>>> >>> >> wrote: >>>> >>> >>>> >>>> I don't really think that we need this level of process around a Wildfly >>>> >>>> Core release. I think that we should just be doing these releases fairly >>>> >>>> frequently, and if some work misses the release then there is always >>>> >>>> another release coming up in the near future. >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> wildfly-dev mailing list >>>> >>>wildfly-dev at lists.jboss.org >>>> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>>> >> _______________________________________________ >>>> >> wildfly-dev mailing list >>>> >>wildfly-dev at lists.jboss.org >>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >> >>>> >> _______________________________________________ >>>> >> wildfly-dev mailing list >>>> >>wildfly-dev at lists.jboss.org >>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> > >>>> > >>>> > _______________________________________________ >>>> > wildfly-dev mailing list >>>> >wildfly-dev at lists.jboss.org >>>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> > >>>> >>>> -- >>>> - DML >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From bilge at redhat.com Thu Oct 9 09:53:07 2014 From: bilge at redhat.com (Bilgehan Ozpeynirci) Date: Thu, 9 Oct 2014 09:53:07 -0400 (EDT) Subject: [wildfly-dev] Deliver 3rd party subsystem to customers? In-Reply-To: <20141009112739.GC5052@hibernate.org> References: <43C4D1A3-7256-4436-A093-A5B321C1DC06@redhat.com> <054697E9-9395-466F-9BD1-EFBD58EB0ED0@redhat.com> <54298BFB.2040309@redhat.com> <130544E0-64E1-4A18-B552-F0405146CF8D@redhat.com> <20141009112739.GC5052@hibernate.org> Message-ID: <1947791824.19855475.1412862787962.JavaMail.zimbra@redhat.com> Yes: https://developer.jboss.org/wiki/WildflyProvisioning -Bilge ----- Original Message ----- | From: "Emmanuel Bernard" | To: "Jason Greene" | Cc: wildfly-dev at lists.jboss.org | Sent: Thursday, October 9, 2014 7:27:39 AM | Subject: Re: [wildfly-dev] Deliver 3rd party subsystem to customers? | I'm interested in that kind of ability as well. | Is there a wiki describing the what and how I could lurke and contribute | on the use cases side? | Emmanuel | On Mon 2014-09-29 11:56, Jason Greene wrote: | > Yeah this is a key goal of features. | > | > You can do something like "feature install org.blah.feature?, and it | > fetches it from maven and installs it. | > | > On Sep 29, 2014, at 11:42 AM, Brian Stansberry | > wrote: | > | > > Agreed. I see feature-packs as the best solution to this kind of thing. | > > | > > CLI archives are another possibility, with the archive bundling the | > > module and then the script executes to install it and make needed mods, | > > but my instinct is the feature-pack stuff will end up being a better | > > approach. | > > | > > On 9/29/14, 11:30 AM, Heiko Braun wrote: | > >> I think the recently added feature packs work that way. Stuart wrote | > >> about that last week: | > >> http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002919.html | > >> | > >> | > >> | > >> | > >> | > >> | > >>> Am 29.09.2014 um 13:36 schrieb "Heiko W.Rupp" : | > >>> | > >>> Hey, | > >>> | > >>> suppose I am writing a subsystem for WildFly, that I can or want not | > >>> add to the generic WildFly codebase (e.g. because it is not open | > >>> source or because WildFly team would consider it too special for | > >>> general consumption). | > >>> | > >>> Is there a way to package that up in a .zip or any other format (in the | > >>> good 'ol days we used .shar files :-) | > >>> to deliver such a subsystem with its module but also the xsl to modify | > >>> standalone.xml (or similar)? | > >>> | > >>> If not (yet), would it make sense for WildFly to reconsider allowing to | > >>> provide e.g. | > >>> * ext.xml | > >>> * subsystem.xml | > >>> * ports.xml | > >>> | > >>> that will get merged / added to standalone.xml when the module is | > >>> loaded for the very first time | > >>> (like when the module.jar is also indexed for the first time). | > >>> | > >>> Thanks | > >>> Heiko | > >>> | > >>> | > >>> _______________________________________________ | > >>> 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 | > >> | > > | > > | > > -- | > > 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 | > | > -- | > Jason T. Greene | > WildFly Lead / JBoss EAP Platform Architect | > JBoss, a division of Red Hat | > | > | > _______________________________________________ | > 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/20141009/cf9fede9/attachment.html From david.lloyd at redhat.com Thu Oct 9 10:23:17 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 09 Oct 2014 09:23:17 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54368CE4.1010901@redhat.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> <543551C3.2000908@redhat.com> <54359DF8.7030707@gmail.com> <543685D5.4040006@jboss.com> <54368CE4.1010901@redhat.com> Message-ID: <54369A55.3060905@redhat.com> On 10/09/2014 08:25 AM, Brian Stansberry wrote: > On 10/9/14, 7:55 AM, Darran Lofthouse wrote: >> Could we make an agreement that all PRs submitted by say Thursday >> afternoon that are ready to be merged are merged before the tag is created. >> > > Given the "ready to be merged" bit, sure, fine with me. > > I'm not willing to commit to people to get things reviewed and tested on > a weekly deadline, but if things are already reviewed and tested I have > no problem promising to merge them. > > I'm just one of the players here, unless I'm nominated as the person who > does the weekly release, in which case my promise matters more. But I > volunteer to do the release if Jason wants that. I agree 100% and I also volunteer to be on the weekly release roster (more people means less likely to miss a release). >> Not saying that Friday's PRs can't be merged just trying to engineers >> some predictability when they are working on issues that affect both repos. >> >> Regards, >> Darran Lofthouse. >> >> >> On 08/10/14 21:26, Stuart Douglas wrote: >>> I think the best way to deal with this is just a time boxed release, say >>> every Friday afternoon. That way there is no surprises, and if a PR is >>> not ready then it can go into next weeks release. >>> >>> I don't think automation is a good idea, there are to many things that >>> can go wrong. >>> >>> Stuart >>> >>> David M. Lloyd wrote: >>>> I'll take whatever I can get. :-) >>>> >>>> On 10/08/2014 10:00 AM, Toma? Cerar wrote: >>>>> that still doesnt solve the problem on "when" next release is. >>>>> >>>>> as people that need to do work across both repos need to know this info. >>>>> Current state is just too unknown and annoyng if you need to do >>>>> something in core and then also in full to make it work. >>>>> not to even add to the mix that your PR *needs* to break something in >>>>> full, at least until your PR for full is also merged. >>>>> >>>>> >>>>> >>>>> On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd>>>> > wrote: >>>>> >>>>> Just telling people "hey I'm releasing core in a day or two" is already >>>>> 10x better than the current status quo. >>>>> >>>>> On 10/08/2014 07:40 AM, Kabir Khan wrote: >>>>> > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P >>>>> > On 8 Oct 2014, at 13:24, Toma? Cerar> wrote: >>>>> > >>>>> >> I had some discussions with Jason on how we could automate >>>>> >> time boxed releases by just having a button in CI that would perform it. >>>>> >> So we at least have a bit of human interaction. >>>>> >> >>>>> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >>>>> >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >>>>> >> >>>>> >> -- >>>>> >> tomaz >>>>> >> >>>>> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse> wrote: >>>>> >> I don't know if it needs to be a short timebox say weekly or better if >>>>> >> on-demand e.g. if an engineer is working on an issue in both core and >>>>> >> wildfly they request a core release and upgrade to continue their work. >>>>> >> >>>>> >> At the same time I think we do need the Jiras as David suggests to track >>>>> >> what we actually needs, unfortunately this does create some additional >>>>> >> maintenance as these need updating after each release. >>>>> >> >>>>> >> On 08/10/14 07:21, Heiko Braun wrote: >>>>> >>> Does it help to put Core on a time boxed schedule? >>>>> >>> >>>>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >>>>> >>> >> wrote: >>>>> >>> >>>>> >>>> I don't really think that we need this level of process around a Wildfly >>>>> >>>> Core release. I think that we should just be doing these releases fairly >>>>> >>>> frequently, and if some work misses the release then there is always >>>>> >>>> another release coming up in the near future. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> wildfly-dev mailing list >>>>> >>>wildfly-dev at lists.jboss.org >>>>> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>> >>>>> >> _______________________________________________ >>>>> >> wildfly-dev mailing list >>>>> >>wildfly-dev at lists.jboss.org >>>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >> >>>>> >> _______________________________________________ >>>>> >> wildfly-dev mailing list >>>>> >>wildfly-dev at lists.jboss.org >>>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > wildfly-dev mailing list >>>>> >wildfly-dev at lists.jboss.org >>>>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> > >>>>> >>>>> -- >>>>> - DML >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- - DML From darran.lofthouse at jboss.com Thu Oct 9 10:42:57 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 09 Oct 2014 15:42:57 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54368CE4.1010901@redhat.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> <543551C3.2000908@redhat.com> <54359DF8.7030707@gmail.com> <543685D5.4040006@jboss.com> <54368CE4.1010901@redhat.com> Message-ID: <54369EF1.6080602@jboss.com> On 09/10/14 14:25, Brian Stansberry wrote: > On 10/9/14, 7:55 AM, Darran Lofthouse wrote: >> Could we make an agreement that all PRs submitted by say Thursday >> afternoon that are ready to be merged are merged before the tag is created. >> > > Given the "ready to be merged" bit, sure, fine with me. +1 Essentially if an engineer has jumped through all of the hoops to get their PR to the point it is acceptable to merge, e.g. test pass, follow up commits following a PR review etc... and this is all complete by the end of Thursday there should be a very high chance their PR will make it into that weeks release. Of course overall there is a risk of merge conflicts but we can never completely eliminate that. > I'm not willing to commit to people to get things reviewed and tested on > a weekly deadline, but if things are already reviewed and tested I have > no problem promising to merge them. > > I'm just one of the players here, unless I'm nominated as the person who > does the weekly release, in which case my promise matters more. But I > volunteer to do the release if Jason wants that. > >> Not saying that Friday's PRs can't be merged just trying to engineers >> some predictability when they are working on issues that affect both repos. >> >> Regards, >> Darran Lofthouse. >> >> >> On 08/10/14 21:26, Stuart Douglas wrote: >>> I think the best way to deal with this is just a time boxed release, say >>> every Friday afternoon. That way there is no surprises, and if a PR is >>> not ready then it can go into next weeks release. >>> >>> I don't think automation is a good idea, there are to many things that >>> can go wrong. >>> >>> Stuart >>> >>> David M. Lloyd wrote: >>>> I'll take whatever I can get. :-) >>>> >>>> On 10/08/2014 10:00 AM, Toma? Cerar wrote: >>>>> that still doesnt solve the problem on "when" next release is. >>>>> >>>>> as people that need to do work across both repos need to know this info. >>>>> Current state is just too unknown and annoyng if you need to do >>>>> something in core and then also in full to make it work. >>>>> not to even add to the mix that your PR *needs* to break something in >>>>> full, at least until your PR for full is also merged. >>>>> >>>>> >>>>> >>>>> On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd>>>> > wrote: >>>>> >>>>> Just telling people "hey I'm releasing core in a day or two" is already >>>>> 10x better than the current status quo. >>>>> >>>>> On 10/08/2014 07:40 AM, Kabir Khan wrote: >>>>> > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P >>>>> > On 8 Oct 2014, at 13:24, Toma? Cerar> wrote: >>>>> > >>>>> >> I had some discussions with Jason on how we could automate >>>>> >> time boxed releases by just having a button in CI that would perform it. >>>>> >> So we at least have a bit of human interaction. >>>>> >> >>>>> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >>>>> >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >>>>> >> >>>>> >> -- >>>>> >> tomaz >>>>> >> >>>>> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse> wrote: >>>>> >> I don't know if it needs to be a short timebox say weekly or better if >>>>> >> on-demand e.g. if an engineer is working on an issue in both core and >>>>> >> wildfly they request a core release and upgrade to continue their work. >>>>> >> >>>>> >> At the same time I think we do need the Jiras as David suggests to track >>>>> >> what we actually needs, unfortunately this does create some additional >>>>> >> maintenance as these need updating after each release. >>>>> >> >>>>> >> On 08/10/14 07:21, Heiko Braun wrote: >>>>> >>> Does it help to put Core on a time boxed schedule? >>>>> >>> >>>>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >>>>> >>> >> wrote: >>>>> >>> >>>>> >>>> I don't really think that we need this level of process around a Wildfly >>>>> >>>> Core release. I think that we should just be doing these releases fairly >>>>> >>>> frequently, and if some work misses the release then there is always >>>>> >>>> another release coming up in the near future. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> wildfly-dev mailing list >>>>> >>>wildfly-dev at lists.jboss.org >>>>> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>> >>>>> >> _______________________________________________ >>>>> >> wildfly-dev mailing list >>>>> >>wildfly-dev at lists.jboss.org >>>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >> >>>>> >> _______________________________________________ >>>>> >> wildfly-dev mailing list >>>>> >>wildfly-dev at lists.jboss.org >>>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > wildfly-dev mailing list >>>>> >wildfly-dev at lists.jboss.org >>>>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> > >>>>> >>>>> -- >>>>> - DML >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From brian.stansberry at redhat.com Thu Oct 9 17:24:00 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 09 Oct 2014 16:24:00 -0500 Subject: [wildfly-dev] Simplification of management "add" handlers Message-ID: <5436FCF0.1000608@redhat.com> FYI, with the integration of wildfly-core 1.0.0.Alpha9 into WildFly one of my screwups has been corrected[1], hopefully making life a bit simpler for subsystem devs. Previously, if you wrote a management handler for an 'add' op, you had to deal with the ServiceVerificationHandler[2], plus record any services you added so they could be rolled back. That's now all handled automatically (as it should have been from the start.) Before you might have had something like the following: public FooAddHandler extends AbstractAddStepHandler { .... protected void performRuntime(final OperationContext context, final ModelNode operation, final ModelNode model, final ServiceVerificationHandler verificationHandler, final List> newControllers) throws OperationFailedException { Service fooService = new FooService(); ServiceBuilder = context.getServiceTarget() .addService(FOO_SERVICE_NAME, fooService) .addListener(verificationHandler); newController.add(builder.install()); } } The above is a simple case; in many cases the boilerplate was worse, e.g. if performRuntime instead delegated to a utility method used to both add the service or to restore it if a "remove" op is rolled back there would be null checks needed for 'verficationHandler' and 'newControllers'. Yuck. Now that method can just be: .... protected void performRuntime(final OperationContext context, final ModelNode operation, final ModelNode model) throws OperationFailedException { Service fooService = new FooService(); context.getServiceTarget() .addService(FOO_SERVICE_NAME, fooService) .install(); } Same thing applies with the performBoottime() method if your handler extends AbstractBoottimeAddStepHandler. The old methods with the 'verificationHandler' and 'newControllers' params are still there and will be invoked if you don't override the simpler overloaded variants, so existing code still works. The values of the verificationHandler and newControllers params aren't used though; they're just they to prevent NPEs. I see Paul has decided to take advantage of this to simplify some of his subsystems.[2] :-) Cheers, Brian [1] https://github.com/wildfly/wildfly-core/pull/182 [2] The ServiceVerificationHandler was responsible for tracking services associated with an operation so that if any of them have a problem starting, the result for that step will include failure information. This work still happens, but now it's all handled by the OperationContext itself, with no need for devs to worry about it. [3] https://github.com/wildfly/wildfly/pull/6798 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Thu Oct 9 20:47:15 2014 From: jperkins at redhat.com (James R. Perkins) Date: Thu, 09 Oct 2014 17:47:15 -0700 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543685D5.4040006@jboss.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> <543551C3.2000908@redhat.com> <54359DF8.7030707@gmail.com> <543685D5.4040006@jboss.com> Message-ID: <54372C93.8010404@redhat.com> With the various time zones we should define "Thursday afternoon". On 10/09/2014 05:55 AM, Darran Lofthouse wrote: > Could we make an agreement that all PRs submitted by say Thursday > afternoon that are ready to be merged are merged before the tag is created. > > Not saying that Friday's PRs can't be merged just trying to engineers > some predictability when they are working on issues that affect both repos. > > Regards, > Darran Lofthouse. > > > On 08/10/14 21:26, Stuart Douglas wrote: >> I think the best way to deal with this is just a time boxed release, say >> every Friday afternoon. That way there is no surprises, and if a PR is >> not ready then it can go into next weeks release. >> >> I don't think automation is a good idea, there are to many things that >> can go wrong. >> >> Stuart >> >> David M. Lloyd wrote: >>> I'll take whatever I can get. :-) >>> >>> On 10/08/2014 10:00 AM, Toma? Cerar wrote: >>>> that still doesnt solve the problem on "when" next release is. >>>> >>>> as people that need to do work across both repos need to know this info. >>>> Current state is just too unknown and annoyng if you need to do >>>> something in core and then also in full to make it work. >>>> not to even add to the mix that your PR *needs* to break something in >>>> full, at least until your PR for full is also merged. >>>> >>>> >>>> >>>> On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd>>> > wrote: >>>> >>>> Just telling people "hey I'm releasing core in a day or two" is already >>>> 10x better than the current status quo. >>>> >>>> On 10/08/2014 07:40 AM, Kabir Khan wrote: >>>> > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P >>>> > On 8 Oct 2014, at 13:24, Toma? Cerar> wrote: >>>> > >>>> >> I had some discussions with Jason on how we could automate >>>> >> time boxed releases by just having a button in CI that would perform it. >>>> >> So we at least have a bit of human interaction. >>>> >> >>>> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >>>> >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >>>> >> >>>> >> -- >>>> >> tomaz >>>> >> >>>> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse> wrote: >>>> >> I don't know if it needs to be a short timebox say weekly or better if >>>> >> on-demand e.g. if an engineer is working on an issue in both core and >>>> >> wildfly they request a core release and upgrade to continue their work. >>>> >> >>>> >> At the same time I think we do need the Jiras as David suggests to track >>>> >> what we actually needs, unfortunately this does create some additional >>>> >> maintenance as these need updating after each release. >>>> >> >>>> >> On 08/10/14 07:21, Heiko Braun wrote: >>>> >>> Does it help to put Core on a time boxed schedule? >>>> >>> >>>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >>>> >>> >> wrote: >>>> >>> >>>> >>>> I don't really think that we need this level of process around a Wildfly >>>> >>>> Core release. I think that we should just be doing these releases fairly >>>> >>>> frequently, and if some work misses the release then there is always >>>> >>>> another release coming up in the near future. >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> wildfly-dev mailing list >>>> >>>wildfly-dev at lists.jboss.org >>>> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>>> >> _______________________________________________ >>>> >> wildfly-dev mailing list >>>> >>wildfly-dev at lists.jboss.org >>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >> >>>> >> _______________________________________________ >>>> >> wildfly-dev mailing list >>>> >>wildfly-dev at lists.jboss.org >>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> > >>>> > >>>> > _______________________________________________ >>>> > wildfly-dev mailing list >>>> >wildfly-dev at lists.jboss.org >>>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> > >>>> >>>> -- >>>> - DML >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat From darran.lofthouse at jboss.com Fri Oct 10 04:29:08 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 10 Oct 2014 09:29:08 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54372C93.8010404@redhat.com> References: <543412FB.8060805@redhat.com> <54344810.8000805@gmail.com> <2760B76B-359B-45C8-9C73-0B513CCF4DDD@redhat.com> <54351295.6080303@jboss.com> <9CE689CF-54E3-468A-ADF5-9B8818BAC95A@jboss.com> <543550D2.3040407@redhat.com> <543551C3.2000908@redhat.com> <54359DF8.7030707@gmail.com> <543685D5.4040006@jboss.com> <54372C93.8010404@redhat.com> Message-ID: <543798D4.2000807@jboss.com> Timezones was the reason I suggested the day before the tagging, everyones Thursday afternoon should have concluded before we reach the Friday afternoon that tagging is occurring in. Apart from a bit of overlap from the US to Australia even the Friday mornings have minimal overlap regardless of which timezone tagging will occur in. But really it should translate to the engineer that knows they are tagging during their afternoon should ensure the PR queue is cleared of all acceptable PRs in the queue that were ready to be merged when they start their day before they tag. Having said all of that in general engineers should be trying to avoid expecting a last minute PR in, clean test runs need to have happened and a review should have already happened - if a review has not already happened it is probably unfair to expect that of the tagger unless the PR is really trivial. Regards, Darran Lofthouse. On 10/10/14 01:47, James R. Perkins wrote: > With the various time zones we should define "Thursday afternoon". > > On 10/09/2014 05:55 AM, Darran Lofthouse wrote: >> Could we make an agreement that all PRs submitted by say Thursday >> afternoon that are ready to be merged are merged before the tag is created. >> >> Not saying that Friday's PRs can't be merged just trying to engineers >> some predictability when they are working on issues that affect both repos. >> >> Regards, >> Darran Lofthouse. >> >> >> On 08/10/14 21:26, Stuart Douglas wrote: >>> I think the best way to deal with this is just a time boxed release, say >>> every Friday afternoon. That way there is no surprises, and if a PR is >>> not ready then it can go into next weeks release. >>> >>> I don't think automation is a good idea, there are to many things that >>> can go wrong. >>> >>> Stuart >>> >>> David M. Lloyd wrote: >>>> I'll take whatever I can get. :-) >>>> >>>> On 10/08/2014 10:00 AM, Toma? Cerar wrote: >>>>> that still doesnt solve the problem on "when" next release is. >>>>> >>>>> as people that need to do work across both repos need to know this info. >>>>> Current state is just too unknown and annoyng if you need to do >>>>> something in core and then also in full to make it work. >>>>> not to even add to the mix that your PR *needs* to break something in >>>>> full, at least until your PR for full is also merged. >>>>> >>>>> >>>>> >>>>> On Wed, Oct 8, 2014 at 4:57 PM, David M. Lloyd>>>> > wrote: >>>>> >>>>> Just telling people "hey I'm releasing core in a day or two" is already >>>>> 10x better than the current status quo. >>>>> >>>>> On 10/08/2014 07:40 AM, Kabir Khan wrote: >>>>> > I think I prefer the 'human interaction' one best. What if the automatic one does the release, just as someone is attempting to merge a bunch of PRs which should be in the release? Although that might be a corner case :-P >>>>> > On 8 Oct 2014, at 13:24, Toma? Cerar> wrote: >>>>> > >>>>> >> I had some discussions with Jason on how we could automate >>>>> >> time boxed releases by just having a button in CI that would perform it. >>>>> >> So we at least have a bit of human interaction. >>>>> >> >>>>> >> We could also have it done automatically by CI every week on schedule that shouldn't be a big deal to do. >>>>> >> If we do that we should have "indexed" build versions like 1.0.0.Beta1-01, 1.0.0.Beta1-02 etc... >>>>> >> >>>>> >> -- >>>>> >> tomaz >>>>> >> >>>>> >> On Wed, Oct 8, 2014 at 12:31 PM, Darran Lofthouse> wrote: >>>>> >> I don't know if it needs to be a short timebox say weekly or better if >>>>> >> on-demand e.g. if an engineer is working on an issue in both core and >>>>> >> wildfly they request a core release and upgrade to continue their work. >>>>> >> >>>>> >> At the same time I think we do need the Jiras as David suggests to track >>>>> >> what we actually needs, unfortunately this does create some additional >>>>> >> maintenance as these need updating after each release. >>>>> >> >>>>> >> On 08/10/14 07:21, Heiko Braun wrote: >>>>> >>> Does it help to put Core on a time boxed schedule? >>>>> >>> >>>>> >>> On 07 Oct 2014, at 22:07, Stuart Douglas >>>>> >>> >> wrote: >>>>> >>> >>>>> >>>> I don't really think that we need this level of process around a Wildfly >>>>> >>>> Core release. I think that we should just be doing these releases fairly >>>>> >>>> frequently, and if some work misses the release then there is always >>>>> >>>> another release coming up in the near future. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> wildfly-dev mailing list >>>>> >>>wildfly-dev at lists.jboss.org >>>>> >>>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>> >>>>> >> _______________________________________________ >>>>> >> wildfly-dev mailing list >>>>> >>wildfly-dev at lists.jboss.org >>>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >> >>>>> >> _______________________________________________ >>>>> >> wildfly-dev mailing list >>>>> >>wildfly-dev at lists.jboss.org >>>>> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > wildfly-dev mailing list >>>>> >wildfly-dev at lists.jboss.org >>>>> >https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> > >>>>> >>>>> -- >>>>> - DML >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Fri Oct 10 09:38:13 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 10 Oct 2014 08:38:13 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543412FB.8060805@redhat.com> References: <543412FB.8060805@redhat.com> Message-ID: <5437E145.3020703@redhat.com> OK so it seems like we have a sort of consensus here. To summarize: ? WildFly Core releases will happen at some nonspecific time on each Friday (but only if there have actually been changes that warrant a release, of course, i.e. there's something that would block somebody's progress in some area) ? Release will be done by Stuart or another core team member as appropriate/needed ? Merge team will make a best effort to merge everything that is marked ready-for-merge by Thursday end-of-day ? People submitting changes should have no reasonable expectation that last minute changes will be merged unless they are trivial ? All WildFly Core update JIRAs will be parented to this JIRA: https://issues.jboss.org/browse/WFLY-3956 ? Since the last release was this past Tuesday, we'll start this no sooner than next week I think that's about it. I'm sure you all will correct me if I missed something. :) -- - DML From jason.greene at redhat.com Fri Oct 10 09:54:53 2014 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 10 Oct 2014 08:54:53 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <5437E145.3020703@redhat.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> Message-ID: <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> I don?t think Stuart officially volunteered? Don?t forget that our Friday is his Saturday, and his Friday is our Thursday. Brain volunteered though. I was planning on doing it, but if he (or anyone else is up for thats great), he (or anyone else) can continue to charge me beer debt :) On Oct 10, 2014, at 8:38 AM, David M. Lloyd wrote: > OK so it seems like we have a sort of consensus here. To summarize: > > ? WildFly Core releases will happen at some nonspecific time on each > Friday (but only if there have actually been changes that warrant a > release, of course, i.e. there's something that would block somebody's > progress in some area) > ? Release will be done by Stuart or another core team member as > appropriate/needed > ? Merge team will make a best effort to merge everything that is marked > ready-for-merge by Thursday end-of-day > ? People submitting changes should have no reasonable expectation that > last minute changes will be merged unless they are trivial > ? All WildFly Core update JIRAs will be parented to this JIRA: > https://issues.jboss.org/browse/WFLY-3956 > ? Since the last release was this past Tuesday, we'll start this no > sooner than next week > > I think that's about it. I'm sure you all will correct me if I missed > something. :) > -- > - DML > _______________________________________________ > 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 david.lloyd at redhat.com Fri Oct 10 10:06:51 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 10 Oct 2014 09:06:51 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> Message-ID: <5437E7FB.1000807@redhat.com> See? Corrections! :-) At least three volunteers so far, so I think we're solid either way. On 10/10/2014 08:54 AM, Jason Greene wrote: > I don?t think Stuart officially volunteered? Don?t forget that our Friday is his Saturday, and his Friday is our Thursday. > > Brain volunteered though. I was planning on doing it, but if he (or anyone else is up for thats great), he (or anyone else) can continue to charge me beer debt :) > > On Oct 10, 2014, at 8:38 AM, David M. Lloyd wrote: > >> OK so it seems like we have a sort of consensus here. To summarize: >> >> ? WildFly Core releases will happen at some nonspecific time on each >> Friday (but only if there have actually been changes that warrant a >> release, of course, i.e. there's something that would block somebody's >> progress in some area) >> ? Release will be done by Stuart or another core team member as >> appropriate/needed >> ? Merge team will make a best effort to merge everything that is marked >> ready-for-merge by Thursday end-of-day >> ? People submitting changes should have no reasonable expectation that >> last minute changes will be merged unless they are trivial >> ? All WildFly Core update JIRAs will be parented to this JIRA: >> https://issues.jboss.org/browse/WFLY-3956 >> ? Since the last release was this past Tuesday, we'll start this no >> sooner than next week >> >> I think that's about it. I'm sure you all will correct me if I missed >> something. :) >> -- >> - DML >> _______________________________________________ >> 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 > -- - DML From kabir.khan at jboss.com Fri Oct 10 11:09:50 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Fri, 10 Oct 2014 16:09:50 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <5437E7FB.1000807@redhat.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <5437E7FB.1000807@redhat.com> Message-ID: <153DE94B-A19E-464D-B157-4465C252AA9E@jboss.com> I can also help On 10 Oct 2014, at 15:06, David M. Lloyd wrote: > See? Corrections! :-) > > At least three volunteers so far, so I think we're solid either way. > > On 10/10/2014 08:54 AM, Jason Greene wrote: >> I don?t think Stuart officially volunteered? Don?t forget that our Friday is his Saturday, and his Friday is our Thursday. >> >> Brain volunteered though. I was planning on doing it, but if he (or anyone else is up for thats great), he (or anyone else) can continue to charge me beer debt :) >> >> On Oct 10, 2014, at 8:38 AM, David M. Lloyd wrote: >> >>> OK so it seems like we have a sort of consensus here. To summarize: >>> >>> ? WildFly Core releases will happen at some nonspecific time on each >>> Friday (but only if there have actually been changes that warrant a >>> release, of course, i.e. there's something that would block somebody's >>> progress in some area) >>> ? Release will be done by Stuart or another core team member as >>> appropriate/needed >>> ? Merge team will make a best effort to merge everything that is marked >>> ready-for-merge by Thursday end-of-day >>> ? People submitting changes should have no reasonable expectation that >>> last minute changes will be merged unless they are trivial >>> ? All WildFly Core update JIRAs will be parented to this JIRA: >>> https://issues.jboss.org/browse/WFLY-3956 >>> ? Since the last release was this past Tuesday, we'll start this no >>> sooner than next week >>> >>> I think that's about it. I'm sure you all will correct me if I missed >>> something. :) >>> -- >>> - DML >>> _______________________________________________ >>> 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 >> > > -- > - DML > _______________________________________________ > 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 Fri Oct 10 17:28:05 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Sat, 11 Oct 2014 08:28:05 +1100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> Message-ID: <54384F65.5010000@gmail.com> If no one else gets to I can do it first thing Monday (Sunday for everyone else). Stuart Jason Greene wrote: > I don?t think Stuart officially volunteered? Don?t forget that our Friday is his Saturday, and his Friday is our Thursday. > > Brain volunteered though. I was planning on doing it, but if he (or anyone else is up for thats great), he (or anyone else) can continue to charge me beer debt :) > > On Oct 10, 2014, at 8:38 AM, David M. Lloyd wrote: > >> OK so it seems like we have a sort of consensus here. To summarize: >> >> ? WildFly Core releases will happen at some nonspecific time on each >> Friday (but only if there have actually been changes that warrant a >> release, of course, i.e. there's something that would block somebody's >> progress in some area) >> ? Release will be done by Stuart or another core team member as >> appropriate/needed >> ? Merge team will make a best effort to merge everything that is marked >> ready-for-merge by Thursday end-of-day >> ? People submitting changes should have no reasonable expectation that >> last minute changes will be merged unless they are trivial >> ? All WildFly Core update JIRAs will be parented to this JIRA: >> https://issues.jboss.org/browse/WFLY-3956 >> ? Since the last release was this past Tuesday, we'll start this no >> sooner than next week >> >> I think that's about it. I'm sure you all will correct me if I missed >> something. :) >> -- >> - DML >> _______________________________________________ >> 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 > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Fri Oct 10 18:12:33 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 10 Oct 2014 17:12:33 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54384F65.5010000@gmail.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> Message-ID: <543859D1.7090708@redhat.com> We just did a release Tuesday, so why don't we start next week instead? On 10/10/2014 04:28 PM, Stuart Douglas wrote: > If no one else gets to I can do it first thing Monday (Sunday for > everyone else). > > Stuart > > Jason Greene wrote: >> I don?t think Stuart officially volunteered? Don?t forget that our >> Friday is his Saturday, and his Friday is our Thursday. >> >> Brain volunteered though. I was planning on doing it, but if he (or >> anyone else is up for thats great), he (or anyone else) can continue >> to charge me beer debt :) >> >> On Oct 10, 2014, at 8:38 AM, David M. Lloyd >> wrote: >> >>> OK so it seems like we have a sort of consensus here. To summarize: >>> >>> ? WildFly Core releases will happen at some nonspecific time on each >>> Friday (but only if there have actually been changes that warrant a >>> release, of course, i.e. there's something that would block somebody's >>> progress in some area) >>> ? Release will be done by Stuart or another core team member as >>> appropriate/needed >>> ? Merge team will make a best effort to merge everything that is marked >>> ready-for-merge by Thursday end-of-day >>> ? People submitting changes should have no reasonable expectation that >>> last minute changes will be merged unless they are trivial >>> ? All WildFly Core update JIRAs will be parented to this JIRA: >>> https://issues.jboss.org/browse/WFLY-3956 >>> ? Since the last release was this past Tuesday, we'll start this no >>> sooner than next week >>> >>> I think that's about it. I'm sure you all will correct me if I missed >>> something. :) >>> -- >>> - DML >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- - DML From stuart.w.douglas at gmail.com Fri Oct 10 18:37:12 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Sat, 11 Oct 2014 09:37:12 +1100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543859D1.7090708@redhat.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> <543859D1.7090708@redhat.com> Message-ID: <54385F98.5030904@gmail.com> I meant in the general case, not this week in particular :-) Stuart David M. Lloyd wrote: > We just did a release Tuesday, so why don't we start next week instead? > > On 10/10/2014 04:28 PM, Stuart Douglas wrote: >> If no one else gets to I can do it first thing Monday (Sunday for >> everyone else). >> >> Stuart >> >> Jason Greene wrote: >>> I don?t think Stuart officially volunteered? Don?t forget that our >>> Friday is his Saturday, and his Friday is our Thursday. >>> >>> Brain volunteered though. I was planning on doing it, but if he (or >>> anyone else is up for thats great), he (or anyone else) can continue >>> to charge me beer debt :) >>> >>> On Oct 10, 2014, at 8:38 AM, David M. Lloyd >>> wrote: >>> >>>> OK so it seems like we have a sort of consensus here. To summarize: >>>> >>>> ? WildFly Core releases will happen at some nonspecific time on each >>>> Friday (but only if there have actually been changes that warrant a >>>> release, of course, i.e. there's something that would block somebody's >>>> progress in some area) >>>> ? Release will be done by Stuart or another core team member as >>>> appropriate/needed >>>> ? Merge team will make a best effort to merge everything that is marked >>>> ready-for-merge by Thursday end-of-day >>>> ? People submitting changes should have no reasonable expectation that >>>> last minute changes will be merged unless they are trivial >>>> ? All WildFly Core update JIRAs will be parented to this JIRA: >>>> https://issues.jboss.org/browse/WFLY-3956 >>>> ? Since the last release was this past Tuesday, we'll start this no >>>> sooner than next week >>>> >>>> I think that's about it. I'm sure you all will correct me if I missed >>>> something. :) >>>> -- >>>> - DML >>>> _______________________________________________ >>>> 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 >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jperkins at redhat.com Fri Oct 10 19:31:16 2014 From: jperkins at redhat.com (James R. Perkins) Date: Fri, 10 Oct 2014 16:31:16 -0700 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <153DE94B-A19E-464D-B157-4465C252AA9E@jboss.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <5437E7FB.1000807@redhat.com> <153DE94B-A19E-464D-B157-4465C252AA9E@jboss.com> Message-ID: <54386C44.2030902@redhat.com> I've got the latest afternoon so I don't mind helping out either :) On 10/10/2014 08:09 AM, Kabir Khan wrote: > I can also help > On 10 Oct 2014, at 15:06, David M. Lloyd wrote: > >> See? Corrections! :-) >> >> At least three volunteers so far, so I think we're solid either way. >> >> On 10/10/2014 08:54 AM, Jason Greene wrote: >>> I don?t think Stuart officially volunteered? Don?t forget that our Friday is his Saturday, and his Friday is our Thursday. >>> >>> Brain volunteered though. I was planning on doing it, but if he (or anyone else is up for thats great), he (or anyone else) can continue to charge me beer debt :) >>> >>> On Oct 10, 2014, at 8:38 AM, David M. Lloyd wrote: >>> >>>> OK so it seems like we have a sort of consensus here. To summarize: >>>> >>>> ? WildFly Core releases will happen at some nonspecific time on each >>>> Friday (but only if there have actually been changes that warrant a >>>> release, of course, i.e. there's something that would block somebody's >>>> progress in some area) >>>> ? Release will be done by Stuart or another core team member as >>>> appropriate/needed >>>> ? Merge team will make a best effort to merge everything that is marked >>>> ready-for-merge by Thursday end-of-day >>>> ? People submitting changes should have no reasonable expectation that >>>> last minute changes will be merged unless they are trivial >>>> ? All WildFly Core update JIRAs will be parented to this JIRA: >>>> https://issues.jboss.org/browse/WFLY-3956 >>>> ? Since the last release was this past Tuesday, we'll start this no >>>> sooner than next week >>>> >>>> I think that's about it. I'm sure you all will correct me if I missed >>>> something. :) >>>> -- >>>> - DML >>>> _______________________________________________ >>>> 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 >>> >> -- >> - DML >> _______________________________________________ >> 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 -- James R. Perkins JBoss by Red Hat From qutpeter at gmail.com Mon Oct 13 05:45:25 2014 From: qutpeter at gmail.com (Peter Cai) Date: Mon, 13 Oct 2014 19:45:25 +1000 Subject: [wildfly-dev] smoke testing failed Message-ID: Hi, It looks like the current HEAD of Wildfly will fail when running smoke testing with the following failure information: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141013/0668b4f1/attachment.html From qutpeter at gmail.com Mon Oct 13 05:47:33 2014 From: qutpeter at gmail.com (Peter Cai) Date: Mon, 13 Oct 2014 19:47:33 +1000 Subject: [wildfly-dev] smoke testing failure Message-ID: Hi, It looks like that the current HEAD of Wildfly will failed when running smoke testing with the following information: Results : Failed tests: ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, 342ae7aec9bff370e3de8704ed9642a718986e61]> but was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> Any cues? Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141013/d0cf13c1/attachment.html From tomaz.cerar at gmail.com Mon Oct 13 06:29:52 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 13 Oct 2014 12:29:52 +0200 Subject: [wildfly-dev] smoke testing failure In-Reply-To: References: Message-ID: os? jvm? arch? looking at our nightly jobs whole testsuite passes on our CI with JDK7 & 8 on windows and on linux. I am guessing it must be environmental issue. On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai wrote: > Hi, > > It looks like that the current HEAD of Wildfly will failed when running > smoke testing with the following information: > > Results : > > Failed tests: > > ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, > 342ae7aec9bff370e3de8704ed9642a718986e61]> but > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> > > Any cues? > > Regards, > > _______________________________________________ > 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/20141013/51c360ac/attachment.html From darran.lofthouse at jboss.com Mon Oct 13 06:33:38 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 13 Oct 2014 11:33:38 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54385F98.5030904@gmail.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> <543859D1.7090708@redhat.com> <54385F98.5030904@gmail.com> Message-ID: <543BAA82.6050106@jboss.com> On 10/10/14 23:37, Stuart Douglas wrote: > I meant in the general case, not this week in particular :-) +1 I think from a predictability perspective for the majority of engineers this means that it is the start of the week that they see Wildfly with an updated core which overall is what we are trying to meet. > Stuart > > David M. Lloyd wrote: >> We just did a release Tuesday, so why don't we start next week instead? >> >> On 10/10/2014 04:28 PM, Stuart Douglas wrote: >>> If no one else gets to I can do it first thing Monday (Sunday for >>> everyone else). >>> >>> Stuart >>> >>> Jason Greene wrote: >>>> I don?t think Stuart officially volunteered? Don?t forget that our >>>> Friday is his Saturday, and his Friday is our Thursday. >>>> >>>> Brain volunteered though. I was planning on doing it, but if he (or >>>> anyone else is up for thats great), he (or anyone else) can continue >>>> to charge me beer debt :) >>>> >>>> On Oct 10, 2014, at 8:38 AM, David M. Lloyd >>>> wrote: >>>> >>>>> OK so it seems like we have a sort of consensus here. To summarize: >>>>> >>>>> ? WildFly Core releases will happen at some nonspecific time on each >>>>> Friday (but only if there have actually been changes that warrant a >>>>> release, of course, i.e. there's something that would block somebody's >>>>> progress in some area) >>>>> ? Release will be done by Stuart or another core team member as >>>>> appropriate/needed >>>>> ? Merge team will make a best effort to merge everything that is marked >>>>> ready-for-merge by Thursday end-of-day >>>>> ? People submitting changes should have no reasonable expectation that >>>>> last minute changes will be merged unless they are trivial >>>>> ? All WildFly Core update JIRAs will be parented to this JIRA: >>>>> https://issues.jboss.org/browse/WFLY-3956 >>>>> ? Since the last release was this past Tuesday, we'll start this no >>>>> sooner than next week >>>>> >>>>> I think that's about it. I'm sure you all will correct me if I missed >>>>> something. :) >>>>> -- >>>>> - DML >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 jose.e.chavez at gmail.com Mon Oct 13 08:49:52 2014 From: jose.e.chavez at gmail.com (jose.e.chavez at gmail.com) Date: Mon, 13 Oct 2014 07:49:52 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <54384F65.5010000@gmail.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> Message-ID: <20141013124952.6054033.37014.7995@gmail.com> Sent from my BlackBerry 10 smartphone. ? Original Message ? From: Stuart Douglas Sent: Friday, October 10, 2014 4:28 PM To: Jason Greene Cc: wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] WildFly Core component upgrade coordination If no one else gets to I can do it first thing Monday (Sunday for everyone else). Stuart Jason Greene wrote: > I don?t think Stuart officially volunteered? Don?t forget that our Friday is his Saturday, and his Friday is our Thursday. > > Brain volunteered though. I was planning on doing it, but if he (or anyone else is up for thats great), he (or anyone else) can continue to charge me beer debt :) > > On Oct 10, 2014, at 8:38 AM, David M. Lloyd wrote: > >> OK so it seems like we have a sort of consensus here. To summarize: >> >> ? WildFly Core releases will happen at some nonspecific time on each >> Friday (but only if there have actually been changes that warrant a >> release, of course, i.e. there's something that would block somebody's >> progress in some area) >> ? Release will be done by Stuart or another core team member as >> appropriate/needed >> ? Merge team will make a best effort to merge everything that is marked >> ready-for-merge by Thursday end-of-day >> ? People submitting changes should have no reasonable expectation that >> last minute changes will be merged unless they are trivial >> ? All WildFly Core update JIRAs will be parented to this JIRA: >> https://issues.jboss.org/browse/WFLY-3956 >> ? Since the last release was this past Tuesday, we'll start this no >> sooner than next week >> >> I think that's about it. I'm sure you all will correct me if I missed >> something. :) >> -- >> - DML >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 jose.e.chavez at gmail.com Mon Oct 13 08:49:59 2014 From: jose.e.chavez at gmail.com (jose.e.chavez at gmail.com) Date: Mon, 13 Oct 2014 07:49:59 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543BAA82.6050106@jboss.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> <543859D1.7090708@redhat.com> <54385F98.5030904@gmail.com> <543BAA82.6050106@jboss.com> Message-ID: <20141013124959.6054033.91809.7996@gmail.com>


  Original Message  
From: Darran Lofthouse
Sent: Monday, October 13, 2014 5:33 AM
To: Stuart Douglas; David M. Lloyd
Cc: wildfly-dev at lists.jboss.org
Subject: Re: [wildfly-dev] WildFly Core component upgrade coordination

On 10/10/14 23:37, Stuart Douglas wrote:
> I meant in the general case, not this week in particular :-)

+1 I think from a predictability perspective for the majority of
engineers this means that it is the start of the week that they see
Wildfly with an updated core which overall is what we are trying to meet.

> Stuart
>
> David M. Lloyd wrote:
>> We just did a release Tuesday, so why don't we start next week instead?
>>
>> On 10/10/2014 04:28 PM, Stuart Douglas wrote:
>>> If no one else gets to I can do it first thing Monday (Sunday for
>>> everyone else).
>>>
>>> Stuart
>>>
>>> Jason Greene wrote:
>>>> I don?t think Stuart officially volunteered? Don?t forget that our
>>>> Friday is his Saturday, and his Friday is our Thursday.
>>>>
>>>> Brain volunteered though. I was planning on doing it, but if he (or
>>>> anyone else is up for thats great), he (or anyone else) can continue
>>>> to charge me beer debt :)
>>>>
>>>> On Oct 10, 2014, at 8:38 AM, David M. Lloyd<david.lloyd at redhat.com>
>>>> wrote:
>>>>
>>>>> OK so it seems like we have a sort of consensus here. To summarize:
>>>>>
>>>>> ? WildFly Core releases will happen at some nonspecific time on each
>>>>> Friday (but only if there have actually been changes that warrant a
>>>>> release, of course, i.e. there's something that would block somebody's
>>>>> progress in some area)
>>>>> ? Release will be done by Stuart or another core team member as
>>>>> appropriate/needed
>>>>> ? Merge team will make a best effort to merge everything that is marked
>>>>> ready-for-merge by Thursday end-of-day
>>>>> ? People submitting changes should have no reasonable expectation that
>>>>> last minute changes will be merged unless they are trivial
>>>>> ? All WildFly Core update JIRAs will be parented to this JIRA:
>>>>> https://issues.jboss.org/browse/WFLY-3956
>>>>> ? Since the last release was this past Tuesday, we'll start this no
>>>>> sooner than next week
>>>>>
>>>>> I think that's about it. I'm sure you all will correct me if I missed
>>>>> something. :)
>>>>> --
>>>>> - DML
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Mon Oct 13 08:53:56 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 13 Oct 2014 13:53:56 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <20141013124952.6054033.37014.7995@gmail.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> <20141013124952.6054033.37014.7995@gmail.com> Message-ID: <543BCB64.30009@jboss.com> I think your BlackBerry 10 smartphone is not having a good day, I see no content in this message from you and another message is a blob of HTML ;-) On 13/10/14 13:49, jose.e.chavez at gmail.com wrote: > > > Sent from my BlackBerry 10 smartphone. > Original Message > From: Stuart Douglas > Sent: Friday, October 10, 2014 4:28 PM > To: Jason Greene > Cc: wildfly-dev at lists.jboss.org > Subject: Re: [wildfly-dev] WildFly Core component upgrade coordination > > If no one else gets to I can do it first thing Monday (Sunday for > everyone else). > > Stuart > > Jason Greene wrote: >> I don?t think Stuart officially volunteered? Don?t forget that our Friday is his Saturday, and his Friday is our Thursday. >> >> Brain volunteered though. I was planning on doing it, but if he (or anyone else is up for thats great), he (or anyone else) can continue to charge me beer debt :) >> >> On Oct 10, 2014, at 8:38 AM, David M. Lloyd wrote: >> >>> OK so it seems like we have a sort of consensus here. To summarize: >>> >>> ? WildFly Core releases will happen at some nonspecific time on each >>> Friday (but only if there have actually been changes that warrant a >>> release, of course, i.e. there's something that would block somebody's >>> progress in some area) >>> ? Release will be done by Stuart or another core team member as >>> appropriate/needed >>> ? Merge team will make a best effort to merge everything that is marked >>> ready-for-merge by Thursday end-of-day >>> ? People submitting changes should have no reasonable expectation that >>> last minute changes will be merged unless they are trivial >>> ? All WildFly Core update JIRAs will be parented to this JIRA: >>> https://issues.jboss.org/browse/WFLY-3956 >>> ? Since the last release was this past Tuesday, we'll start this no >>> sooner than next week >>> >>> I think that's about it. I'm sure you all will correct me if I missed >>> something. :) >>> -- >>> - DML >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From eduardo.santanadasilva at gmail.com Mon Oct 13 11:39:58 2014 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Mon, 13 Oct 2014 12:39:58 -0300 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543BCB64.30009@jboss.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> <20141013124952.6054033.37014.7995@gmail.com> <543BCB64.30009@jboss.com> Message-ID: This is the broken html content: :) On 10/10/14 23:37, Stuart Douglas wrote: > I meant in the general case, not this week in particular :-) +1 I think from a predictability perspective for the majority of engineers this means that it is the start of the week that they see Wildfly with an updated core which overall is what we are trying to meet. > Stuart > > David M. Lloyd wrote: >> We just did a release Tuesday, so why don't we start next week instead? >> >> On 10/10/2014 04:28 PM, Stuart Douglas wrote: >>> If no one else gets to I can do it first thing Monday (Sunday for >>> everyone else). >>> >>> Stuart >>> >>> Jason Greene wrote: >>>> I don???t think Stuart officially volunteered? Don???t forget that our >>>> Friday is his Saturday, and his Friday is our Thursday. >>>> >>>> Brain volunteered though. I was planning on doing it, but if he (or >>>> anyone else is up for thats great), he (or anyone else) can continue >>>> to charge me beer debt :) >>>> >>>> On Oct 10, 2014, at 8:38 AM, David M. Lloyd >>>> wrote: >>>> >>>>> OK so it seems like we have a sort of consensus here. To summarize: >>>>> >>>>> ??? WildFly Core releases will happen at some nonspecific time on each >>>>> Friday (but only if there have actually been changes that warrant a >>>>> release, of course, i.e. there's something that would block somebody's >>>>> progress in some area) >>>>> ??? Release will be done by Stuart or another core team member as >>>>> appropriate/needed >>>>> ??? Merge team will make a best effort to merge everything that is marked >>>>> ready-for-merge by Thursday end-of-day >>>>> ??? People submitting changes should have no reasonable expectation that >>>>> last minute changes will be merged unless they are trivial >>>>> ??? All WildFly Core update JIRAs will be parented to this JIRA: >>>>> https://issues.jboss.org/browse/WFLY-3956 >>>>> ??? Since the last release was this past Tuesday, we'll start this no >>>>> sooner than next week >>>>> >>>>> I think that's about it. I'm sure you all will correct me if I missed >>>>> something. :) >>>>> -- >>>>> - DML >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev 2014-10-13 9:53 GMT-03:00 Darran Lofthouse : > I think your BlackBerry 10 smartphone is not having a good day, I see no > content in this message from you and another message is a blob of HTML ;-) > > On 13/10/14 13:49, jose.e.chavez at gmail.com wrote: > > > > > > Sent from my BlackBerry 10 smartphone. > > Original Message > > From: Stuart Douglas > > Sent: Friday, October 10, 2014 4:28 PM > > To: Jason Greene > > Cc: wildfly-dev at lists.jboss.org > > Subject: Re: [wildfly-dev] WildFly Core component upgrade coordination > > > > If no one else gets to I can do it first thing Monday (Sunday for > > everyone else). > > > > Stuart > > > > Jason Greene wrote: > >> I don?t think Stuart officially volunteered? Don?t forget that our > Friday is his Saturday, and his Friday is our Thursday. > >> > >> Brain volunteered though. I was planning on doing it, but if he (or > anyone else is up for thats great), he (or anyone else) can continue to > charge me beer debt :) > >> > >> On Oct 10, 2014, at 8:38 AM, David M. Lloyd > wrote: > >> > >>> OK so it seems like we have a sort of consensus here. To summarize: > >>> > >>> ? WildFly Core releases will happen at some nonspecific time on each > >>> Friday (but only if there have actually been changes that warrant a > >>> release, of course, i.e. there's something that would block somebody's > >>> progress in some area) > >>> ? Release will be done by Stuart or another core team member as > >>> appropriate/needed > >>> ? Merge team will make a best effort to merge everything that is marked > >>> ready-for-merge by Thursday end-of-day > >>> ? People submitting changes should have no reasonable expectation that > >>> last minute changes will be merged unless they are trivial > >>> ? All WildFly Core update JIRAs will be parented to this JIRA: > >>> https://issues.jboss.org/browse/WFLY-3956 > >>> ? Since the last release was this past Tuesday, we'll start this no > >>> sooner than next week > >>> > >>> I think that's about it. I'm sure you all will correct me if I missed > >>> something. :) > >>> -- > >>> - DML > >>> _______________________________________________ > >>> 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 > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva 2014-10-13 9:53 GMT-03:00 Darran Lofthouse : > I think your BlackBerry 10 smartphone is not having a good day, I see no > content in this message from you and another message is a blob of HTML ;-) > > On 13/10/14 13:49, jose.e.chavez at gmail.com wrote: > > > > > > Sent from my BlackBerry 10 smartphone. > > Original Message > > From: Stuart Douglas > > Sent: Friday, October 10, 2014 4:28 PM > > To: Jason Greene > > Cc: wildfly-dev at lists.jboss.org > > Subject: Re: [wildfly-dev] WildFly Core component upgrade coordination > > > > If no one else gets to I can do it first thing Monday (Sunday for > > everyone else). > > > > Stuart > > > > Jason Greene wrote: > >> I don?t think Stuart officially volunteered? Don?t forget that our > Friday is his Saturday, and his Friday is our Thursday. > >> > >> Brain volunteered though. I was planning on doing it, but if he (or > anyone else is up for thats great), he (or anyone else) can continue to > charge me beer debt :) > >> > >> On Oct 10, 2014, at 8:38 AM, David M. Lloyd > wrote: > >> > >>> OK so it seems like we have a sort of consensus here. To summarize: > >>> > >>> ? WildFly Core releases will happen at some nonspecific time on each > >>> Friday (but only if there have actually been changes that warrant a > >>> release, of course, i.e. there's something that would block somebody's > >>> progress in some area) > >>> ? Release will be done by Stuart or another core team member as > >>> appropriate/needed > >>> ? Merge team will make a best effort to merge everything that is marked > >>> ready-for-merge by Thursday end-of-day > >>> ? People submitting changes should have no reasonable expectation that > >>> last minute changes will be merged unless they are trivial > >>> ? All WildFly Core update JIRAs will be parented to this JIRA: > >>> https://issues.jboss.org/browse/WFLY-3956 > >>> ? Since the last release was this past Tuesday, we'll start this no > >>> sooner than next week > >>> > >>> I think that's about it. I'm sure you all will correct me if I missed > >>> something. :) > >>> -- > >>> - DML > >>> _______________________________________________ > >>> 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 > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141013/4eb42122/attachment.html From ssilvert at redhat.com Mon Oct 13 14:30:11 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 13 Oct 2014 14:30:11 -0400 Subject: [wildfly-dev] AddStepHandler can't add content to overlay Message-ID: <543C1A33.8040208@redhat.com> I have an AddStepHandler that adds a keycloak server to the management model using the "Mixed Approach"[1]. It also needs to add overlay content if any new content is available. The overlay itself already exists in standalone.xml. I insert this operation in my AddStepHandler: { "operation" => "add", "address" => [ ("deployment-overlay" => "main-auth-server.war-keycloak-overlay"), ("content" => "/WEB-INF/classes/META-INF/keycloak-server.json") ], "content" => {"url" => "file:/mydir/keycloak-server.json"}, "rollback-on-runtime-failure" => false } But at this point in server startup, the overlay's add handler hasn't bee called. So I get 14:09:20,729 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 26) JBAS014613: Operation ("add") failed - address: ([ ("deployment-overlay" => "main-auth-server.war-keycloak-overlay"), ("content" => "/WEB-INF/classes/META-INF/keycloak-server.json") ]) - failure description: "JBAS014766: Resource [(\"deployment-overlay\" => \"main-auth-server.war-keycloak-overlay\")] does not exist; a resource at address [ (\"deployment-overlay\" => \"main-auth-server.war-keycloak-overlay\"), (\"content\" => \"/WEB-INF/classes/META-INF/keycloak-server.json\") ] cannot be created until all ancestor resources have been added" At startup, how can I make sure that my "add overlay content" operation is executed after "add overlay" is done? [1] https://developer.jboss.org/wiki/ExtendingAS7 From brian.stansberry at redhat.com Mon Oct 13 16:12:25 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 13 Oct 2014 15:12:25 -0500 Subject: [wildfly-dev] AddStepHandler can't add content to overlay In-Reply-To: <543C1A33.8040208@redhat.com> References: <543C1A33.8040208@redhat.com> Message-ID: <543C3229.9090309@redhat.com> There's no way now to make sure it runs after. But the fact it assumes that overlay is present in the first place sounds fishy. How do you know it exists? On 10/13/14, 1:30 PM, Stan Silvert wrote: > I have an AddStepHandler that adds a keycloak server to the management > model using the "Mixed Approach"[1]. It also needs to add overlay > content if any new content is available. The overlay itself already > exists in standalone.xml. > > > > > > > I insert this operation in my AddStepHandler: > { > "operation" => "add", > "address" => [ > ("deployment-overlay" => "main-auth-server.war-keycloak-overlay"), > ("content" => "/WEB-INF/classes/META-INF/keycloak-server.json") > ], > "content" => {"url" => "file:/mydir/keycloak-server.json"}, > "rollback-on-runtime-failure" => false > } > > But at this point in server startup, the overlay's add handler hasn't > bee called. So I get > 14:09:20,729 ERROR [org.jboss.as.controller.management-operation] > (ServerService Thread Pool -- 26) JBAS014613: Operation ("add") failed - > address: ([ > ("deployment-overlay" => "main-auth-server.war-keycloak-overlay"), > ("content" => "/WEB-INF/classes/META-INF/keycloak-server.json") > ]) - failure description: "JBAS014766: Resource [(\"deployment-overlay\" > => \"main-auth-server.war-keycloak-overlay\")] does not exist; a > resource at address [ > (\"deployment-overlay\" => \"main-auth-server.war-keycloak-overlay\"), > (\"content\" => \"/WEB-INF/classes/META-INF/keycloak-server.json\") > ] cannot be created until all ancestor resources have been added" > > At startup, how can I make sure that my "add overlay content" operation > is executed after "add overlay" is done? > > [1] https://developer.jboss.org/wiki/ExtendingAS7 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ssilvert at redhat.com Mon Oct 13 16:19:54 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 13 Oct 2014 16:19:54 -0400 Subject: [wildfly-dev] AddStepHandler can't add content to overlay In-Reply-To: <543C3229.9090309@redhat.com> References: <543C1A33.8040208@redhat.com> <543C3229.9090309@redhat.com> Message-ID: <543C33EA.4060409@redhat.com> On 10/13/2014 4:12 PM, Brian Stansberry wrote: > There's no way now to make sure it runs after. > > But the fact it assumes that overlay is present in the first place > sounds fishy. How do you know it exists? You don't know it exists. But if it does, you get an error. This wouldn't be a problem if I could have non-persistent overlays, but I guess I can't? https://issues.jboss.org/browse/WFLY-3955 > > On 10/13/14, 1:30 PM, Stan Silvert wrote: >> I have an AddStepHandler that adds a keycloak server to the management >> model using the "Mixed Approach"[1]. It also needs to add overlay >> content if any new content is available. The overlay itself already >> exists in standalone.xml. >> >> > name="main-auth-server.war-keycloak-overlay"> >> >> >> >> >> I insert this operation in my AddStepHandler: >> { >> "operation" => "add", >> "address" => [ >> ("deployment-overlay" => >> "main-auth-server.war-keycloak-overlay"), >> ("content" => "/WEB-INF/classes/META-INF/keycloak-server.json") >> ], >> "content" => {"url" => "file:/mydir/keycloak-server.json"}, >> "rollback-on-runtime-failure" => false >> } >> >> But at this point in server startup, the overlay's add handler hasn't >> bee called. So I get >> 14:09:20,729 ERROR [org.jboss.as.controller.management-operation] >> (ServerService Thread Pool -- 26) JBAS014613: Operation ("add") failed - >> address: ([ >> ("deployment-overlay" => "main-auth-server.war-keycloak-overlay"), >> ("content" => "/WEB-INF/classes/META-INF/keycloak-server.json") >> ]) - failure description: "JBAS014766: Resource [(\"deployment-overlay\" >> => \"main-auth-server.war-keycloak-overlay\")] does not exist; a >> resource at address [ >> (\"deployment-overlay\" => >> \"main-auth-server.war-keycloak-overlay\"), >> (\"content\" => \"/WEB-INF/classes/META-INF/keycloak-server.json\") >> ] cannot be created until all ancestor resources have been added" >> >> At startup, how can I make sure that my "add overlay content" operation >> is executed after "add overlay" is done? >> >> [1] https://developer.jboss.org/wiki/ExtendingAS7 > > From stuart.w.douglas at gmail.com Mon Oct 13 16:20:48 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 14 Oct 2014 07:20:48 +1100 Subject: [wildfly-dev] AddStepHandler can't add content to overlay In-Reply-To: <543C3229.9090309@redhat.com> References: <543C1A33.8040208@redhat.com> <543C3229.9090309@redhat.com> Message-ID: <543C3420.5070300@gmail.com> Can you elaborate on why you need this? In your previous thread you mentioned user provided content and I suggested that they could use overlays, however this would require the user to install the overlays rather than the subystem. Looking at your example it looks like you are adding keycloak-server.json as an overlay, and I can't help but wonder why? I would guess that you are doing this to allow a deployment to read a file that is external to the deployment to be read from the class loader? If that is the case then I think there are better ways you can approach this (e.g. adding a resource loader to the module that can access this file). Stuart Brian Stansberry wrote: > There's no way now to make sure it runs after. > > But the fact it assumes that overlay is present in the first place > sounds fishy. How do you know it exists? > > On 10/13/14, 1:30 PM, Stan Silvert wrote: >> I have an AddStepHandler that adds a keycloak server to the management >> model using the "Mixed Approach"[1]. It also needs to add overlay >> content if any new content is available. The overlay itself already >> exists in standalone.xml. >> >> >> >> >> >> >> I insert this operation in my AddStepHandler: >> { >> "operation" => "add", >> "address" => [ >> ("deployment-overlay" => "main-auth-server.war-keycloak-overlay"), >> ("content" => "/WEB-INF/classes/META-INF/keycloak-server.json") >> ], >> "content" => {"url" => "file:/mydir/keycloak-server.json"}, >> "rollback-on-runtime-failure" => false >> } >> >> But at this point in server startup, the overlay's add handler hasn't >> bee called. So I get >> 14:09:20,729 ERROR [org.jboss.as.controller.management-operation] >> (ServerService Thread Pool -- 26) JBAS014613: Operation ("add") failed - >> address: ([ >> ("deployment-overlay" => "main-auth-server.war-keycloak-overlay"), >> ("content" => "/WEB-INF/classes/META-INF/keycloak-server.json") >> ]) - failure description: "JBAS014766: Resource [(\"deployment-overlay\" >> => \"main-auth-server.war-keycloak-overlay\")] does not exist; a >> resource at address [ >> (\"deployment-overlay\" => \"main-auth-server.war-keycloak-overlay\"), >> (\"content\" => \"/WEB-INF/classes/META-INF/keycloak-server.json\") >> ] cannot be created until all ancestor resources have been added" >> >> At startup, how can I make sure that my "add overlay content" operation >> is executed after "add overlay" is done? >> >> [1] https://developer.jboss.org/wiki/ExtendingAS7 > > From ssilvert at redhat.com Mon Oct 13 16:26:57 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 13 Oct 2014 16:26:57 -0400 Subject: [wildfly-dev] AddStepHandler can't add content to overlay In-Reply-To: <543C3420.5070300@gmail.com> References: <543C1A33.8040208@redhat.com> <543C3229.9090309@redhat.com> <543C3420.5070300@gmail.com> Message-ID: <543C3591.3010601@redhat.com> On 10/13/2014 4:20 PM, Stuart Douglas wrote: > Can you elaborate on why you need this? > > In your previous thread you mentioned user provided content and I > suggested that they could use overlays, however this would require the > user to install the overlays rather than the subystem. > > Looking at your example it looks like you are adding > keycloak-server.json as an overlay, and I can't help but wonder why? > > I would guess that you are doing this to allow a deployment to read a > file that is external to the deployment to be read from the class > loader? If that is the case then I think there are better ways you can > approach this (e.g. adding a resource loader to the module that can > access this file). The file will usually be a jar containing a service. Can you elaborate on adding a resource loader to the module? > > Stuart > > Brian Stansberry wrote: >> There's no way now to make sure it runs after. >> >> But the fact it assumes that overlay is present in the first place >> sounds fishy. How do you know it exists? >> >> On 10/13/14, 1:30 PM, Stan Silvert wrote: >>> I have an AddStepHandler that adds a keycloak server to the management >>> model using the "Mixed Approach"[1]. It also needs to add overlay >>> content if any new content is available. The overlay itself already >>> exists in standalone.xml. >>> >>> >> name="main-auth-server.war-keycloak-overlay"> >>> >>> >>> >>> >>> I insert this operation in my AddStepHandler: >>> { >>> "operation" => "add", >>> "address" => [ >>> ("deployment-overlay" => >>> "main-auth-server.war-keycloak-overlay"), >>> ("content" => >>> "/WEB-INF/classes/META-INF/keycloak-server.json") >>> ], >>> "content" => {"url" => "file:/mydir/keycloak-server.json"}, >>> "rollback-on-runtime-failure" => false >>> } >>> >>> But at this point in server startup, the overlay's add handler hasn't >>> bee called. So I get >>> 14:09:20,729 ERROR [org.jboss.as.controller.management-operation] >>> (ServerService Thread Pool -- 26) JBAS014613: Operation ("add") >>> failed - >>> address: ([ >>> ("deployment-overlay" => >>> "main-auth-server.war-keycloak-overlay"), >>> ("content" => "/WEB-INF/classes/META-INF/keycloak-server.json") >>> ]) - failure description: "JBAS014766: Resource >>> [(\"deployment-overlay\" >>> => \"main-auth-server.war-keycloak-overlay\")] does not exist; a >>> resource at address [ >>> (\"deployment-overlay\" => >>> \"main-auth-server.war-keycloak-overlay\"), >>> (\"content\" => >>> \"/WEB-INF/classes/META-INF/keycloak-server.json\") >>> ] cannot be created until all ancestor resources have been added" >>> >>> At startup, how can I make sure that my "add overlay content" operation >>> is executed after "add overlay" is done? >>> >>> [1] https://developer.jboss.org/wiki/ExtendingAS7 >> >> From qutpeter at gmail.com Mon Oct 13 19:19:26 2014 From: qutpeter at gmail.com (Peter Cai) Date: Tue, 14 Oct 2014 09:19:26 +1000 Subject: [wildfly-dev] smoke testing failure In-Reply-To: References: Message-ID: It should be some environmental issue. I can successfully run the smoke test on Windows 8, And the JVM is: java version "1.7.0_51" Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) Regards On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai wrote: > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 UTC > 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 14.04 desktop) > > JVM: > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > > My guess is environmental issue as well. But can't find anything so far. > > Regards, > Peter > > > > On Mon, Oct 13, 2014 at 8:29 PM, Toma? Cerar > wrote: > >> os? jvm? arch? >> >> looking at our nightly jobs whole testsuite passes on our CI with JDK7 & >> 8 on windows and on linux. >> >> I am guessing it must be environmental issue. >> >> On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai wrote: >> >>> Hi, >>> >>> It looks like that the current HEAD of Wildfly will failed when running >>> smoke testing with the following information: >>> >>> Results : >>> >>> Failed tests: >>> >>> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 >>> expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, >>> 342ae7aec9bff370e3de8704ed9642a718986e61]> but >>> was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> >>> >>> Any cues? >>> >>> Regards, >>> >>> _______________________________________________ >>> 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/20141014/5dd887b4/attachment.html From eduardo.santanadasilva at gmail.com Mon Oct 13 20:29:11 2014 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Mon, 13 Oct 2014 21:29:11 -0300 Subject: [wildfly-dev] smoke testing failure In-Reply-To: References: Message-ID: I've made the build successfully on the following environment as well: OS X 10.9.5 java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) 2014-10-13 20:19 GMT-03:00 Peter Cai : > It should be some environmental issue. > I can successfully run the smoke test on Windows 8, > > And the JVM is: > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > > Regards > > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai wrote: > >> OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 UTC >> 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 14.04 desktop) >> >> JVM: >> java version "1.7.0_51" >> Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) >> >> My guess is environmental issue as well. But can't find anything so far. >> >> Regards, >> Peter >> >> >> >> On Mon, Oct 13, 2014 at 8:29 PM, Toma? Cerar >> wrote: >> >>> os? jvm? arch? >>> >>> looking at our nightly jobs whole testsuite passes on our CI with JDK7 & >>> 8 on windows and on linux. >>> >>> I am guessing it must be environmental issue. >>> >>> On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai wrote: >>> >>>> Hi, >>>> >>>> It looks like that the current HEAD of Wildfly will failed when running >>>> smoke testing with the following information: >>>> >>>> Results : >>>> >>>> Failed tests: >>>> >>>> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 >>>> expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, >>>> 342ae7aec9bff370e3de8704ed9642a718986e61]> but >>>> was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> >>>> >>>> Any cues? >>>> >>>> Regards, >>>> >>>> _______________________________________________ >>>> 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 > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141013/342add84/attachment-0001.html From ewertz at redhat.com Tue Oct 14 01:19:44 2014 From: ewertz at redhat.com (Edward Wertz) Date: Tue, 14 Oct 2014 01:19:44 -0400 (EDT) Subject: [wildfly-dev] smoke testing failure In-Reply-To: References: Message-ID: <17398798.5184.1413263981421.JavaMail.joe@localhost.localdomain> I've gotten that error for a while, so you're not alone, but haven't been able to track it down either, so I'm not much help fixing it. Java/Maven versions don't effect it and I can build fine on my Windows 7 machine. It's a mystery to me what's causing it. Linux localhost.localdomain 3.16.2-201.fc20.x86_64 #1 SMP Mon Sep 15 19:57:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch Distributor ID: Fedora Description: Fedora release 20 (Heisenbug) Release: 20 Codename: Heisenbug Joe Wertz ----- Original Message ----- > From: "Eduardo Sant?Ana da Silva" > To: "Peter Cai" > Cc: wildfly-dev at lists.jboss.org > Sent: Tuesday, October 14, 2014 8:29:11 AM > Subject: Re: [wildfly-dev] smoke testing failure > > > > I've made the build successfully on the following environment as > well: > > OS X 10.9.5 > java version "1.8.0_05" > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > > 2014-10-13 20:19 GMT-03:00 Peter Cai < qutpeter at gmail.com > : > > It should be some environmental issue. > I can successfully run the smoke test on Windows 8, > > And the JVM is: > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > > Regards > > > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai < qutpeter at gmail.com > > wrote: > > > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 14.04 desktop) > > JVM: > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > > My guess is environmental issue as well. But can't find anything so > far. > > Regards, > > Peter > > > On Mon, Oct 13, 2014 at 8:29 PM, Toma? Cerar < tomaz.cerar at gmail.com > > wrote: > > os? jvm? arch? > > looking at our nightly jobs whole testsuite passes on our CI with > JDK7 & 8 on windows and on linux. > > I am guessing it must be environmental issue. > > > On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai < qutpeter at gmail.com > > wrote: > > Hi, > > It looks like that the current HEAD of Wildfly will failed when > running smoke testing with the following information: > > Results : > > Failed tests: > ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, > 342ae7aec9bff370e3de8704ed9642a718986e61]> but > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> > > Any cues? > > Regards, > > _______________________________________________ > 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 > > > > -- > > > ________________ __________ > > > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From sandyridgeracer at gmail.com Tue Oct 14 03:28:59 2014 From: sandyridgeracer at gmail.com (Sandeep Samdaria) Date: Tue, 14 Oct 2014 12:58:59 +0530 Subject: [wildfly-dev] Building WildFly 9.0.0.Alpha2-SNAPSHOT Message-ID: Hi, I am trying to build wildfly locally. I am facing the errors mentioned below. I had sent a similar mail three weeks ago and got no response. Yesterday, I had posted this on jboss forum https://developer.jboss.org/message/906929. Jaikiran suggested to re-post it to with the latest wildfly code. Environment: *OS* : Ubuntu 12.04(64bit) *Java* : version "1.7.0" Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode) Is there something obvious that I am missing? Please let me know. *Error * sandeep at sandeep:~/development/grails-project/wildfly$ ./build.sh Maven already exists Maven is correct version ./tools/maven/bin/mvn -s tools/maven/conf/settings.xml install [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Reactor Build Order: [INFO] [INFO] WildFly: Parent Aggregator [INFO] WildFly: Naming Subsystem [[[ truncated some of the unrelated logs ]]]] [INFO] WildFly Test Suite: Integration - Smoke [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building WildFly: Parent Aggregator 9.0.0.Alpha2-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (ban-bad-dependencies) @ wildfly-parent --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @ wildfly-parent --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @ wildfly-parent --- [INFO] [INFO] --- buildnumber-maven-plugin:1.3:create-timestamp (get-build-timestamp) @ wildfly-parent --- [INFO] [INFO] --- buildnumber-maven-plugin:1.3:create (get-scm-revision) @ wildfly-parent --- [INFO] Executing: /bin/sh -c cd /home/sandeep/development/grails-project/wildfly && git rev-parse --verify HEAD [INFO] Working directory: /home/sandeep/development/grails-project/wildfly [INFO] Storing buildNumber: 206ad185abcaec3dc00ab87e07e23829bd0baee2 at timestamp: 1413270863566 [INFO] Storing buildScmBranch: master [INFO] [INFO] --- maven-checkstyle-plugin:2.12.1:checkstyle (check-style) @ wildfly-parent --- [INFO] [INFO] --- maven-source-plugin:2.3:jar-no-fork (attach-sources) @ wildfly-parent --- [INFO] [INFO] --- maven-install-plugin:2.5.1:install (default-install) @ wildfly-parent --- [INFO] Installing /home/sandeep/development/grails-project/wildfly/pom.xml to /home/sandeep/.m2/repository/org/wildfly/wildfly-parent/9.0.0.Alpha2-SNAPSHOT/wildfly-parent-9.0.0.Alpha2-SNAPSHOT.pom [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building WildFly: Naming Subsystem 9.0.0.Alpha2-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (ban-bad-dependencies) @ wildfly-naming --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @ wildfly-naming --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @ wildfly-naming --- [INFO] [INFO] --- buildnumber-maven-plugin:1.3:create-timestamp (get-build-timestamp) @ wildfly-naming --- [INFO] [INFO] --- buildnumber-maven-plugin:1.3:create (get-scm-revision) @ wildfly-naming --- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ wildfly-naming --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 9 resources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ wildfly-naming --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 87 source files to /home/sandeep/development/grails-project/wildfly/naming/target/classes [INFO] ------------------------------------------------------------- [WARNING] COMPILATION WARNING : [INFO] ------------------------------------------------------------- [WARNING] /home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/RemoteNamingAdd.java:[30,31] org.jboss.as.controller.ServiceVerificationHandler in org.jboss.as.controller has been deprecated [WARNING] /home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/NamingBindingAdd.java:[41,31] org.jboss.as.controller.ServiceVerificationHandler in org.jboss.as.controller has been deprecated [WARNING] /home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/NamingSubsystemAdd.java:[27,31] org.jboss.as.controller.ServiceVerificationHandler in org.jboss.as.controller has been deprecated [WARNING] /home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/RemoteNamingAdd.java:[30,31] org.jboss.as.controller.ServiceVerificationHandler in org.jboss.as.controller has been deprecated [WARNING] /home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/NamingBindingAdd.java:[41,31] org.jboss.as.controller.ServiceVerificationHandler in org.jboss.as.controller has been deprecated [WARNING] /home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/NamingSubsystemAdd.java:[27,31] org.jboss.as.controller.ServiceVerificationHandler in org.jboss.as.controller has been deprecated [INFO] 6 warnings [INFO] ------------------------------------------------------------- [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] Cannot read org.jboss.as.naming.logging package files, cause : java.io.FileNotFoundException: org.jboss.as.naming.logging/NamingLogger at com.sun.tools.javac.processing.JavacFiler.getResource(JavacFiler.java:464) at org.jboss.logging.processor.apt.TranslationClassGenerator.findTranslationFiles(TranslationClassGenerator.java:152) at org.jboss.logging.processor.apt.TranslationClassGenerator.processTypeElement(TranslationClassGenerator.java:115) at org.jboss.logging.processor.apt.LoggingToolsProcessor.process(LoggingToolsProcessor.java:145) at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793) at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:722) at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97) at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029) at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1106) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824) at com.sun.tools.javac.main.Main.compile(Main.java:417) at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132) at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169) at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:785) at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) [INFO] 1 error [INFO] ------------------------------------------------------------- [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] WildFly: Parent Aggregator ......................... SUCCESS [ 5.533 s] [INFO] WildFly: Naming Subsystem .......................... FAILURE [ 5.495 s] [INFO] WildFly: EE ........................................ SKIPPED [[[ truncated some of the unrelated logs ]]]] [INFO] WildFly Test Suite: Integration - Smoke ............ SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 20.434 s [INFO] Finished at: 2014-10-14T12:44:31+05:30 [INFO] Final Memory: 170M/465M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project wildfly-naming: Compilation failure [ERROR] Cannot read org.jboss.as.naming.logging package files, cause : java.io.FileNotFoundException: org.jboss.as.naming.logging/NamingLogger [ERROR] at com.sun.tools.javac.processing.JavacFiler.getResource(JavacFiler.java:464) [ERROR] at org.jboss.logging.processor.apt.TranslationClassGenerator.findTranslationFiles(TranslationClassGenerator.java:152) [ERROR] at org.jboss.logging.processor.apt.TranslationClassGenerator.processTypeElement(TranslationClassGenerator.java:115) [ERROR] at org.jboss.logging.processor.apt.LoggingToolsProcessor.process(LoggingToolsProcessor.java:145) [ERROR] at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793) [ERROR] at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:722) [ERROR] at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97) [ERROR] at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029) [ERROR] at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163) [ERROR] at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1106) [ERROR] at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824) [ERROR] at com.sun.tools.javac.main.Main.compile(Main.java:417) [ERROR] at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132) [ERROR] at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) [ERROR] at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169) [ERROR] at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:785) [ERROR] at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129) [ERROR] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) [ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) [ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) [ERROR] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) [ERROR] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347) [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [ERROR] at java.lang.reflect.Method.invoke(Method.java:601) [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :wildfly-naming Thanks, Sandeep. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141014/6ae118f5/attachment-0001.html From tomaz.cerar at gmail.com Tue Oct 14 05:17:18 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 14 Oct 2014 11:17:18 +0200 Subject: [wildfly-dev] Building WildFly 9.0.0.Alpha2-SNAPSHOT In-Reply-To: References: Message-ID: On Tue, Oct 14, 2014 at 9:28 AM, Sandeep Samdaria wrote: > *Java* : version "1.7.0" > Java(TM) SE Runtime Environment (build 1.7.0-b147) > Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode) > Not completely sure what is your problem, but it would start with updating JDK 7 to something more recent. you are running u5, while latest is u67 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141014/4d7e69b9/attachment.html From tomaz.cerar at gmail.com Tue Oct 14 05:23:52 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 14 Oct 2014 11:23:52 +0200 Subject: [wildfly-dev] smoke testing failure In-Reply-To: <17398798.5184.1413263981421.JavaMail.joe@localhost.localdomain> References: <17398798.5184.1413263981421.JavaMail.joe@localhost.localdomain> Message-ID: Guys, is problem only this test or also something else? it is possible that this tests has problems that makes it fail on certain scenarios. Any chance anyone of you that can reproduce it, can try to track it down what the issue is? if you add "-fae -Dmaven.test.failure.ignore=true " as param to build, it will continue building/testing after test failure(s), so you can see what all tests fail for you or only this one. On Tue, Oct 14, 2014 at 7:19 AM, Edward Wertz wrote: > I've gotten that error for a while, so you're not alone, but haven't been > able to track it down either, so I'm not much help fixing it. Java/Maven > versions don't effect it and I can build fine on my Windows 7 machine. It's > a mystery to me what's causing it. > > Linux localhost.localdomain 3.16.2-201.fc20.x86_64 #1 SMP Mon Sep 15 > 19:57:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > LSB Version: > :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch > Distributor ID: Fedora > Description: Fedora release 20 (Heisenbug) > Release: 20 > Codename: Heisenbug > > Joe Wertz > > > ----- Original Message ----- > > From: "Eduardo Sant?Ana da Silva" > > To: "Peter Cai" > > Cc: wildfly-dev at lists.jboss.org > > Sent: Tuesday, October 14, 2014 8:29:11 AM > > Subject: Re: [wildfly-dev] smoke testing failure > > > > > > > > I've made the build successfully on the following environment as > > well: > > > > OS X 10.9.5 > > java version "1.8.0_05" > > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > > > > > 2014-10-13 20:19 GMT-03:00 Peter Cai < qutpeter at gmail.com > : > > > > It should be some environmental issue. > > I can successfully run the smoke test on Windows 8, > > > > And the JVM is: > > java version "1.7.0_51" > > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > > > > Regards > > > > > > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai < qutpeter at gmail.com > > > wrote: > > > > > > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 > > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 14.04 desktop) > > > > JVM: > > java version "1.7.0_51" > > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) > > > > My guess is environmental issue as well. But can't find anything so > > far. > > > > Regards, > > > > Peter > > > > > > On Mon, Oct 13, 2014 at 8:29 PM, Toma? Cerar < tomaz.cerar at gmail.com > > > wrote: > > > > os? jvm? arch? > > > > looking at our nightly jobs whole testsuite passes on our CI with > > JDK7 & 8 on windows and on linux. > > > > I am guessing it must be environmental issue. > > > > > > On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai < qutpeter at gmail.com > > > wrote: > > > > Hi, > > > > It looks like that the current HEAD of Wildfly will failed when > > running smoke testing with the following information: > > > > Results : > > > > Failed tests: > > > ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 > > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, > > 342ae7aec9bff370e3de8704ed9642a718986e61]> but > > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> > > > > Any cues? > > > > Regards, > > > > _______________________________________________ > > 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 > > > > > > > > -- > > > > > > ________________ __________ > > > > > > Eduardo Sant'Ana da Silva - Dr. > > Pesquisador / Consultor de TI > > > > > > > > _______________________________________________ > > 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/20141014/8829367f/attachment.html From tomaz.cerar at gmail.com Tue Oct 14 05:51:45 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 14 Oct 2014 11:51:45 +0200 Subject: [wildfly-dev] IPv6 testing changes Message-ID: Hi guys, JGroups update exposed a problem with our ipv6 testing on our CI. To fix that we had to modify the network configuration on all build agents and config how ipv6 testsuite is ran. As part of work we also simplified testing on ipv6 where now all you need to pass to testsuite is -Dipv6. for anyone of you that runs ipv6 testsuite locally on linux add this config for your network: # Allow loopback to multicast ip -6 route add table local local ff13::/16 dev lo metric 5 # Add an additional "unique" address to lo for clustering tests ifconfig lo add fccc::2/128 Anyone that has currently open PR that is not merged yet, to rebase them as otherwise you will get clustering & domain ipv6 related test failures. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141014/46fb6d0a/attachment.html From qutpeter at gmail.com Tue Oct 14 08:33:29 2014 From: qutpeter at gmail.com (Peter Cai) Date: Tue, 14 Oct 2014 22:33:29 +1000 Subject: [wildfly-dev] smoke testing failure In-Reply-To: References: <17398798.5184.1413263981421.JavaMail.joe@localhost.localdomain> Message-ID: On my side, I use "mvn -fae -Dmaven.test.failure.ignore=true clean install", this test mentioned above is the only test that failed. I am trying to track it down. Regards, Peter On Tue, Oct 14, 2014 at 7:23 PM, Toma? Cerar wrote: > Guys, is problem only this test or also something else? > > it is possible that this tests has problems that makes it fail on certain > scenarios. > > Any chance anyone of you that can reproduce it, can try to track it down > what the issue is? > > if you add "-fae -Dmaven.test.failure.ignore=true " as param to build, it > will continue building/testing after test failure(s), > so you can see what all tests fail for you or only this one. > > On Tue, Oct 14, 2014 at 7:19 AM, Edward Wertz wrote: > >> I've gotten that error for a while, so you're not alone, but haven't been >> able to track it down either, so I'm not much help fixing it. Java/Maven >> versions don't effect it and I can build fine on my Windows 7 machine. It's >> a mystery to me what's causing it. >> >> Linux localhost.localdomain 3.16.2-201.fc20.x86_64 #1 SMP Mon Sep 15 >> 19:57:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >> LSB Version: >> :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch >> Distributor ID: Fedora >> Description: Fedora release 20 (Heisenbug) >> Release: 20 >> Codename: Heisenbug >> >> Joe Wertz >> >> >> ----- Original Message ----- >> > From: "Eduardo Sant?Ana da Silva" >> > To: "Peter Cai" >> > Cc: wildfly-dev at lists.jboss.org >> > Sent: Tuesday, October 14, 2014 8:29:11 AM >> > Subject: Re: [wildfly-dev] smoke testing failure >> > >> > >> > >> > I've made the build successfully on the following environment as >> > well: >> > >> > OS X 10.9.5 >> > java version "1.8.0_05" >> > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >> > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >> > >> > >> > 2014-10-13 20:19 GMT-03:00 Peter Cai < qutpeter at gmail.com > : >> > >> > It should be some environmental issue. >> > I can successfully run the smoke test on Windows 8, >> > >> > And the JVM is: >> > java version "1.7.0_51" >> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) >> > >> > Regards >> > >> > >> > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai < qutpeter at gmail.com > >> > wrote: >> > >> > >> > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 >> > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 14.04 desktop) >> > >> > JVM: >> > java version "1.7.0_51" >> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) >> > >> > My guess is environmental issue as well. But can't find anything so >> > far. >> > >> > Regards, >> > >> > Peter >> > >> > >> > On Mon, Oct 13, 2014 at 8:29 PM, Toma? Cerar < tomaz.cerar at gmail.com >> > > wrote: >> > >> > os? jvm? arch? >> > >> > looking at our nightly jobs whole testsuite passes on our CI with >> > JDK7 & 8 on windows and on linux. >> > >> > I am guessing it must be environmental issue. >> > >> > >> > On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai < qutpeter at gmail.com > >> > wrote: >> > >> > Hi, >> > >> > It looks like that the current HEAD of Wildfly will failed when >> > running smoke testing with the following information: >> > >> > Results : >> > >> > Failed tests: >> > >> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 >> > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, >> > 342ae7aec9bff370e3de8704ed9642a718986e61]> but >> > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> >> > >> > Any cues? >> > >> > Regards, >> > >> > _______________________________________________ >> > 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 >> > >> > >> > >> > -- >> > >> > >> > ________________ __________ >> > >> > >> > Eduardo Sant'Ana da Silva - Dr. >> > Pesquisador / Consultor de TI >> > >> > >> > >> > _______________________________________________ >> > 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/20141014/c34c54e1/attachment-0001.html From sandyridgeracer at gmail.com Tue Oct 14 08:38:27 2014 From: sandyridgeracer at gmail.com (Sandeep Samdaria) Date: Tue, 14 Oct 2014 18:08:27 +0530 Subject: [wildfly-dev] Building WildFly 9.0.0.Alpha2-SNAPSHOT In-Reply-To: References: Message-ID: Yup, that worked for me. In addition to updating the jdk from u5 to u67, I also had to point JAVA_HOME to the latest. I wanted to contribute to wildfly project. Any minor/trivial ticket which I can take a look into it as a newbie? -Sandeep. On Tue, Oct 14, 2014 at 2:47 PM, Toma? Cerar wrote: > > On Tue, Oct 14, 2014 at 9:28 AM, Sandeep Samdaria < > sandyridgeracer at gmail.com> wrote: > >> *Java* : version "1.7.0" >> Java(TM) SE Runtime Environment (build 1.7.0-b147) >> Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode) >> > > > Not completely sure what is your problem, but it would start with updating > JDK 7 to something more recent. > you are running u5, while latest is u67 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141014/b3eb9748/attachment.html From qutpeter at gmail.com Wed Oct 15 00:40:53 2014 From: qutpeter at gmail.com (Peter Cai) Date: Wed, 15 Oct 2014 14:40:53 +1000 Subject: [wildfly-dev] smoke testing failure In-Reply-To: References: <17398798.5184.1413263981421.JavaMail.joe@localhost.localdomain> Message-ID: Well, I have no luck on tracking down what is happening in this test case. But things is becoming more interesting. I can partially repeat the failure on Windows 8. Now, on both Ubuntu 14.04 and Windows 8, using JVM 1.7.0_51, run the test from the smoke testing module. i.e., cd testsuite\integration\smoke mvn clean test -Dtest=org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase Interestingly, this testcase sometimes passes, sometimes fails. When failed, with the following info: Failed tests: ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 expected:<[504917ff8990a5f90995d412117e39afbdaf6747]> but was:<[]> Regards, Peter On Tue, Oct 14, 2014 at 10:33 PM, Peter Cai wrote: > On my side, I use "mvn -fae -Dmaven.test.failure.ignore=true clean > install", this test mentioned above is the only test that failed. > > I am trying to track it down. > > Regards, > Peter > > On Tue, Oct 14, 2014 at 7:23 PM, Toma? Cerar > wrote: > >> Guys, is problem only this test or also something else? >> >> it is possible that this tests has problems that makes it fail on certain >> scenarios. >> >> Any chance anyone of you that can reproduce it, can try to track it down >> what the issue is? >> >> if you add "-fae -Dmaven.test.failure.ignore=true " as param to build, it >> will continue building/testing after test failure(s), >> so you can see what all tests fail for you or only this one. >> >> On Tue, Oct 14, 2014 at 7:19 AM, Edward Wertz wrote: >> >>> I've gotten that error for a while, so you're not alone, but haven't >>> been able to track it down either, so I'm not much help fixing it. >>> Java/Maven versions don't effect it and I can build fine on my Windows 7 >>> machine. It's a mystery to me what's causing it. >>> >>> Linux localhost.localdomain 3.16.2-201.fc20.x86_64 #1 SMP Mon Sep 15 >>> 19:57:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>> LSB Version: >>> :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch >>> Distributor ID: Fedora >>> Description: Fedora release 20 (Heisenbug) >>> Release: 20 >>> Codename: Heisenbug >>> >>> Joe Wertz >>> >>> >>> ----- Original Message ----- >>> > From: "Eduardo Sant?Ana da Silva" >>> > To: "Peter Cai" >>> > Cc: wildfly-dev at lists.jboss.org >>> > Sent: Tuesday, October 14, 2014 8:29:11 AM >>> > Subject: Re: [wildfly-dev] smoke testing failure >>> > >>> > >>> > >>> > I've made the build successfully on the following environment as >>> > well: >>> > >>> > OS X 10.9.5 >>> > java version "1.8.0_05" >>> > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>> > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>> > >>> > >>> > 2014-10-13 20:19 GMT-03:00 Peter Cai < qutpeter at gmail.com > : >>> > >>> > It should be some environmental issue. >>> > I can successfully run the smoke test on Windows 8, >>> > >>> > And the JVM is: >>> > java version "1.7.0_51" >>> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >>> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) >>> > >>> > Regards >>> > >>> > >>> > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai < qutpeter at gmail.com > >>> > wrote: >>> > >>> > >>> > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 >>> > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 14.04 desktop) >>> > >>> > JVM: >>> > java version "1.7.0_51" >>> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >>> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) >>> > >>> > My guess is environmental issue as well. But can't find anything so >>> > far. >>> > >>> > Regards, >>> > >>> > Peter >>> > >>> > >>> > On Mon, Oct 13, 2014 at 8:29 PM, Toma? Cerar < tomaz.cerar at gmail.com >>> > > wrote: >>> > >>> > os? jvm? arch? >>> > >>> > looking at our nightly jobs whole testsuite passes on our CI with >>> > JDK7 & 8 on windows and on linux. >>> > >>> > I am guessing it must be environmental issue. >>> > >>> > >>> > On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai < qutpeter at gmail.com > >>> > wrote: >>> > >>> > Hi, >>> > >>> > It looks like that the current HEAD of Wildfly will failed when >>> > running smoke testing with the following information: >>> > >>> > Results : >>> > >>> > Failed tests: >>> > >>> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 >>> > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, >>> > 342ae7aec9bff370e3de8704ed9642a718986e61]> but >>> > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> >>> > >>> > Any cues? >>> > >>> > Regards, >>> > >>> > _______________________________________________ >>> > 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 >>> > >>> > >>> > >>> > -- >>> > >>> > >>> > ________________ __________ >>> > >>> > >>> > Eduardo Sant'Ana da Silva - Dr. >>> > Pesquisador / Consultor de TI >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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/20141015/20b8bf0d/attachment.html From darran.lofthouse at jboss.com Wed Oct 15 05:04:29 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 15 Oct 2014 10:04:29 +0100 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543BAA82.6050106@jboss.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> <543859D1.7090708@redhat.com> <54385F98.5030904@gmail.com> <543BAA82.6050106@jboss.com> Message-ID: <543E389D.6070703@jboss.com> I think this takes us back to one point to double check. Obviously any engineer can raise a component upgrade Jira in the WildFly-Core project, sometimes there is no immediate rush but other times until the update is there they are blocked from continuing their work in WildFly - what is the best way to indicate the latter? On 13/10/14 11:33, Darran Lofthouse wrote: > On 10/10/14 23:37, Stuart Douglas wrote: >> I meant in the general case, not this week in particular :-) > > +1 I think from a predictability perspective for the majority of > engineers this means that it is the start of the week that they see > Wildfly with an updated core which overall is what we are trying to meet. > >> Stuart >> >> David M. Lloyd wrote: >>> We just did a release Tuesday, so why don't we start next week instead? >>> >>> On 10/10/2014 04:28 PM, Stuart Douglas wrote: >>>> If no one else gets to I can do it first thing Monday (Sunday for >>>> everyone else). >>>> >>>> Stuart >>>> >>>> Jason Greene wrote: >>>>> I don?t think Stuart officially volunteered? Don?t forget that our >>>>> Friday is his Saturday, and his Friday is our Thursday. >>>>> >>>>> Brain volunteered though. I was planning on doing it, but if he (or >>>>> anyone else is up for thats great), he (or anyone else) can continue >>>>> to charge me beer debt :) >>>>> >>>>> On Oct 10, 2014, at 8:38 AM, David M. Lloyd >>>>> wrote: >>>>> >>>>>> OK so it seems like we have a sort of consensus here. To summarize: >>>>>> >>>>>> ? WildFly Core releases will happen at some nonspecific time on each >>>>>> Friday (but only if there have actually been changes that warrant a >>>>>> release, of course, i.e. there's something that would block somebody's >>>>>> progress in some area) >>>>>> ? Release will be done by Stuart or another core team member as >>>>>> appropriate/needed >>>>>> ? Merge team will make a best effort to merge everything that is marked >>>>>> ready-for-merge by Thursday end-of-day >>>>>> ? People submitting changes should have no reasonable expectation that >>>>>> last minute changes will be merged unless they are trivial >>>>>> ? All WildFly Core update JIRAs will be parented to this JIRA: >>>>>> https://issues.jboss.org/browse/WFLY-3956 >>>>>> ? Since the last release was this past Tuesday, we'll start this no >>>>>> sooner than next week >>>>>> >>>>>> I think that's about it. I'm sure you all will correct me if I missed >>>>>> something. :) >>>>>> -- >>>>>> - DML >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Wed Oct 15 08:49:49 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Oct 2014 07:49:49 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543E389D.6070703@jboss.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> <543859D1.7090708@redhat.com> <54385F98.5030904@gmail.com> <543BAA82.6050106@jboss.com> <543E389D.6070703@jboss.com> Message-ID: <543E6D6D.8080407@redhat.com> There are a few things we can do just in JIRA alone, like setting priority to "Blocker", and setting a dependency to the core upgrade issue, and then commenting on the core upgrade issue. Or you could do it in the PR with a comment (or a tag maybe?). On 10/15/2014 04:04 AM, Darran Lofthouse wrote: > I think this takes us back to one point to double check. > > Obviously any engineer can raise a component upgrade Jira in the > WildFly-Core project, sometimes there is no immediate rush but other > times until the update is there they are blocked from continuing their > work in WildFly - what is the best way to indicate the latter? > > On 13/10/14 11:33, Darran Lofthouse wrote: >> On 10/10/14 23:37, Stuart Douglas wrote: >>> I meant in the general case, not this week in particular :-) >> >> +1 I think from a predictability perspective for the majority of >> engineers this means that it is the start of the week that they see >> Wildfly with an updated core which overall is what we are trying to meet. >> >>> Stuart >>> >>> David M. Lloyd wrote: >>>> We just did a release Tuesday, so why don't we start next week instead? >>>> >>>> On 10/10/2014 04:28 PM, Stuart Douglas wrote: >>>>> If no one else gets to I can do it first thing Monday (Sunday for >>>>> everyone else). >>>>> >>>>> Stuart >>>>> >>>>> Jason Greene wrote: >>>>>> I don?t think Stuart officially volunteered? Don?t forget that our >>>>>> Friday is his Saturday, and his Friday is our Thursday. >>>>>> >>>>>> Brain volunteered though. I was planning on doing it, but if he (or >>>>>> anyone else is up for thats great), he (or anyone else) can continue >>>>>> to charge me beer debt :) >>>>>> >>>>>> On Oct 10, 2014, at 8:38 AM, David M. Lloyd >>>>>> wrote: >>>>>> >>>>>>> OK so it seems like we have a sort of consensus here. To summarize: >>>>>>> >>>>>>> ? WildFly Core releases will happen at some nonspecific time on each >>>>>>> Friday (but only if there have actually been changes that warrant a >>>>>>> release, of course, i.e. there's something that would block somebody's >>>>>>> progress in some area) >>>>>>> ? Release will be done by Stuart or another core team member as >>>>>>> appropriate/needed >>>>>>> ? Merge team will make a best effort to merge everything that is marked >>>>>>> ready-for-merge by Thursday end-of-day >>>>>>> ? People submitting changes should have no reasonable expectation that >>>>>>> last minute changes will be merged unless they are trivial >>>>>>> ? All WildFly Core update JIRAs will be parented to this JIRA: >>>>>>> https://issues.jboss.org/browse/WFLY-3956 >>>>>>> ? Since the last release was this past Tuesday, we'll start this no >>>>>>> sooner than next week >>>>>>> >>>>>>> I think that's about it. I'm sure you all will correct me if I missed >>>>>>> something. :) >>>>>>> -- >>>>>>> - DML >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From david.lloyd at redhat.com Wed Oct 15 08:51:18 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Oct 2014 07:51:18 -0500 Subject: [wildfly-dev] WildFly Core component upgrade coordination In-Reply-To: <543E6D6D.8080407@redhat.com> References: <543412FB.8060805@redhat.com> <5437E145.3020703@redhat.com> <9198D5B4-5C76-43F2-81E5-FBE71AD913E2@redhat.com> <54384F65.5010000@gmail.com> <543859D1.7090708@redhat.com> <54385F98.5030904@gmail.com> <543BAA82.6050106@jboss.com> <543E389D.6070703@jboss.com> <543E6D6D.8080407@redhat.com> Message-ID: <543E6DC6.1050700@redhat.com> Labels. I meant labels. On 10/15/2014 07:49 AM, David M. Lloyd wrote: > There are a few things we can do just in JIRA alone, like setting > priority to "Blocker", and setting a dependency to the core upgrade > issue, and then commenting on the core upgrade issue. Or you could do > it in the PR with a comment (or a tag maybe?). > > On 10/15/2014 04:04 AM, Darran Lofthouse wrote: >> I think this takes us back to one point to double check. >> >> Obviously any engineer can raise a component upgrade Jira in the >> WildFly-Core project, sometimes there is no immediate rush but other >> times until the update is there they are blocked from continuing their >> work in WildFly - what is the best way to indicate the latter? >> >> On 13/10/14 11:33, Darran Lofthouse wrote: >>> On 10/10/14 23:37, Stuart Douglas wrote: >>>> I meant in the general case, not this week in particular :-) >>> >>> +1 I think from a predictability perspective for the majority of >>> engineers this means that it is the start of the week that they see >>> Wildfly with an updated core which overall is what we are trying to >>> meet. >>> >>>> Stuart >>>> >>>> David M. Lloyd wrote: >>>>> We just did a release Tuesday, so why don't we start next week >>>>> instead? >>>>> >>>>> On 10/10/2014 04:28 PM, Stuart Douglas wrote: >>>>>> If no one else gets to I can do it first thing Monday (Sunday for >>>>>> everyone else). >>>>>> >>>>>> Stuart >>>>>> >>>>>> Jason Greene wrote: >>>>>>> I don?t think Stuart officially volunteered? Don?t forget that our >>>>>>> Friday is his Saturday, and his Friday is our Thursday. >>>>>>> >>>>>>> Brain volunteered though. I was planning on doing it, but if he (or >>>>>>> anyone else is up for thats great), he (or anyone else) can continue >>>>>>> to charge me beer debt :) >>>>>>> >>>>>>> On Oct 10, 2014, at 8:38 AM, David M. Lloyd >>>>>>> wrote: >>>>>>> >>>>>>>> OK so it seems like we have a sort of consensus here. To summarize: >>>>>>>> >>>>>>>> ? WildFly Core releases will happen at some nonspecific time on >>>>>>>> each >>>>>>>> Friday (but only if there have actually been changes that warrant a >>>>>>>> release, of course, i.e. there's something that would block >>>>>>>> somebody's >>>>>>>> progress in some area) >>>>>>>> ? Release will be done by Stuart or another core team member as >>>>>>>> appropriate/needed >>>>>>>> ? Merge team will make a best effort to merge everything that is >>>>>>>> marked >>>>>>>> ready-for-merge by Thursday end-of-day >>>>>>>> ? People submitting changes should have no reasonable >>>>>>>> expectation that >>>>>>>> last minute changes will be merged unless they are trivial >>>>>>>> ? All WildFly Core update JIRAs will be parented to this JIRA: >>>>>>>> https://issues.jboss.org/browse/WFLY-3956 >>>>>>>> ? Since the last release was this past Tuesday, we'll start this no >>>>>>>> sooner than next week >>>>>>>> >>>>>>>> I think that's about it. I'm sure you all will correct me if I >>>>>>>> missed >>>>>>>> something. :) >>>>>>>> -- >>>>>>>> - DML >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > -- - DML From eduardo.santanadasilva at gmail.com Wed Oct 15 08:58:55 2014 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Wed, 15 Oct 2014 09:58:55 -0300 Subject: [wildfly-dev] smoke testing failure In-Reply-To: References: <17398798.5184.1413263981421.JavaMail.joe@localhost.localdomain> Message-ID: Could be some change regarding some message digest used on ShrinkWrap API based upon a different JVM version? Just a guess... --- Eduardo Sant'Ana da Silva 2014-10-15 1:40 GMT-03:00 Peter Cai : > Well, I have no luck on tracking down what is happening in this test case. > But things is becoming more interesting. > > I can partially repeat the failure on Windows 8. > > Now, on both Ubuntu 14.04 and Windows 8, using JVM 1.7.0_51, > run the test from the smoke testing module. i.e., > > cd testsuite\integration\smoke > mvn clean test > -Dtest=org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase > > Interestingly, this testcase sometimes passes, sometimes fails. When > failed, with the following info: > > Failed tests: > > ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 > expected:<[504917ff8990a5f90995d412117e39afbdaf6747]> but was:<[]> > > > Regards, > Peter > > On Tue, Oct 14, 2014 at 10:33 PM, Peter Cai wrote: > >> On my side, I use "mvn -fae -Dmaven.test.failure.ignore=true clean >> install", this test mentioned above is the only test that failed. >> >> I am trying to track it down. >> >> Regards, >> Peter >> >> On Tue, Oct 14, 2014 at 7:23 PM, Toma? Cerar >> wrote: >> >>> Guys, is problem only this test or also something else? >>> >>> it is possible that this tests has problems that makes it fail on >>> certain scenarios. >>> >>> Any chance anyone of you that can reproduce it, can try to track it down >>> what the issue is? >>> >>> if you add "-fae -Dmaven.test.failure.ignore=true " as param to build, >>> it will continue building/testing after test failure(s), >>> so you can see what all tests fail for you or only this one. >>> >>> On Tue, Oct 14, 2014 at 7:19 AM, Edward Wertz wrote: >>> >>>> I've gotten that error for a while, so you're not alone, but haven't >>>> been able to track it down either, so I'm not much help fixing it. >>>> Java/Maven versions don't effect it and I can build fine on my Windows 7 >>>> machine. It's a mystery to me what's causing it. >>>> >>>> Linux localhost.localdomain 3.16.2-201.fc20.x86_64 #1 SMP Mon Sep 15 >>>> 19:57:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >>>> LSB Version: >>>> :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch >>>> Distributor ID: Fedora >>>> Description: Fedora release 20 (Heisenbug) >>>> Release: 20 >>>> Codename: Heisenbug >>>> >>>> Joe Wertz >>>> >>>> >>>> ----- Original Message ----- >>>> > From: "Eduardo Sant?Ana da Silva" >>>> > To: "Peter Cai" >>>> > Cc: wildfly-dev at lists.jboss.org >>>> > Sent: Tuesday, October 14, 2014 8:29:11 AM >>>> > Subject: Re: [wildfly-dev] smoke testing failure >>>> > >>>> > >>>> > >>>> > I've made the build successfully on the following environment as >>>> > well: >>>> > >>>> > OS X 10.9.5 >>>> > java version "1.8.0_05" >>>> > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>>> > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>>> > >>>> > >>>> > 2014-10-13 20:19 GMT-03:00 Peter Cai < qutpeter at gmail.com > : >>>> > >>>> > It should be some environmental issue. >>>> > I can successfully run the smoke test on Windows 8, >>>> > >>>> > And the JVM is: >>>> > java version "1.7.0_51" >>>> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >>>> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) >>>> > >>>> > Regards >>>> > >>>> > >>>> > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai < qutpeter at gmail.com > >>>> > wrote: >>>> > >>>> > >>>> > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 >>>> > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 14.04 desktop) >>>> > >>>> > JVM: >>>> > java version "1.7.0_51" >>>> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >>>> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) >>>> > >>>> > My guess is environmental issue as well. But can't find anything so >>>> > far. >>>> > >>>> > Regards, >>>> > >>>> > Peter >>>> > >>>> > >>>> > On Mon, Oct 13, 2014 at 8:29 PM, Toma? Cerar < tomaz.cerar at gmail.com >>>> > > wrote: >>>> > >>>> > os? jvm? arch? >>>> > >>>> > looking at our nightly jobs whole testsuite passes on our CI with >>>> > JDK7 & 8 on windows and on linux. >>>> > >>>> > I am guessing it must be environmental issue. >>>> > >>>> > >>>> > On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai < qutpeter at gmail.com > >>>> > wrote: >>>> > >>>> > Hi, >>>> > >>>> > It looks like that the current HEAD of Wildfly will failed when >>>> > running smoke testing with the following information: >>>> > >>>> > Results : >>>> > >>>> > Failed tests: >>>> > >>>> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 >>>> > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, >>>> > 342ae7aec9bff370e3de8704ed9642a718986e61]> but >>>> > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> >>>> > >>>> > Any cues? >>>> > >>>> > Regards, >>>> > >>>> > _______________________________________________ >>>> > 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 >>>> > >>>> > >>>> > >>>> > -- >>>> > >>>> > >>>> > ________________ __________ >>>> > >>>> > >>>> > Eduardo Sant'Ana da Silva - Dr. >>>> > Pesquisador / Consultor de TI >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > wildfly-dev mailing list >>>> > wildfly-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141015/6ec5f5d3/attachment.html From jai.forums2013 at gmail.com Wed Oct 15 23:48:35 2014 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 16 Oct 2014 09:18:35 +0530 Subject: [wildfly-dev] Building WildFly 9.0.0.Alpha2-SNAPSHOT In-Reply-To: References: Message-ID: <543F4013.9000308@gmail.com> Sandeep, The WFLY JIRA has some issues which have been marked as "Awaiting for volunteers". Here's a link to such unresolved issues https://issues.jboss.org/issues/?jql=fixVersion%20%3D%20%22Awaiting%20Volunteers%22%20AND%20project%20%3D%20WFLY%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC. You can choose from one of them that interests you. You might want to hang around in the #wildfly-dev channel on IRC (irc.freenode.net server) where the WildFly developers can help you in getting started or working on the issue that you pick. -Jaikiran On Tuesday 14 October 2014 06:08 PM, Sandeep Samdaria wrote: > Yup, that worked for me. In addition to updating the jdk from u5 to > u67, I also had to point JAVA_HOME to the latest. > > > I wanted to contribute to wildfly project. Any minor/trivial ticket > which I can take a look into it as a newbie? > > > -Sandeep. > > On Tue, Oct 14, 2014 at 2:47 PM, Toma? Cerar > wrote: > > > On Tue, Oct 14, 2014 at 9:28 AM, Sandeep Samdaria > > wrote: > > _Java_ : version "1.7.0" > Java(TM) SE Runtime Environment (build 1.7.0-b147) > Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode) > > > > Not completely sure what is your problem, but it would start with > updating JDK 7 to something more recent. > you are running u5, while latest is u67 > > > > > _______________________________________________ > 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/20141016/85a04be7/attachment-0001.html From hbraun at redhat.com Thu Oct 16 04:06:12 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 16 Oct 2014 10:06:12 +0200 Subject: [wildfly-dev] Wildfly-Cassandra Updates Message-ID: <2F16912E-C3A4-4828-B3BE-CDEA13094B3A@redhat.com> A quick heads up about the Cassandra subsystem: As stated before, C* used a lot of System.exit() calls that made the integration with Wildfly [1] a little cumbersome and error prone. But I am glad to see that the Cassandra Developers accepted our patches [2] to remove that hurdle, which means we are one step closer to finishing the actual integration. [1] https://github.com/heiko-braun/wildfly-cassandra [2] https://issues.apache.org/jira/browse/CASSANDRA-7997 Regards, Heiko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141016/5617ba8d/attachment.html From hbraun at redhat.com Thu Oct 16 10:06:52 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 16 Oct 2014 16:06:52 +0200 Subject: [wildfly-dev] Console updates in trunk and 8.x Message-ID: <12341D6C-1275-4280-995E-C0944D660174@redhat.com> We've updated trunk and 8.x to include the most recent 2.4.x HAL console. The details are described here: http://hbraun.info/2014/10/updated-management-console-in-wildfly-8-2/ Regards, Heiko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141016/432f9c1f/attachment.html From psilva at redhat.com Thu Oct 16 10:10:32 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 16 Oct 2014 10:10:32 -0400 (EDT) Subject: [wildfly-dev] Console updates in trunk and 8.x In-Reply-To: <12341D6C-1275-4280-995E-C0944D660174@redhat.com> References: <12341D6C-1275-4280-995E-C0944D660174@redhat.com> Message-ID: <297968938.4851664.1413468632186.JavaMail.zimbra@redhat.com> It really looks nice ... ----- Original Message ----- From: "Heiko Braun" To: "WildFly Dev" Sent: Thursday, October 16, 2014 11:06:52 AM Subject: [wildfly-dev] Console updates in trunk and 8.x We've updated trunk and 8.x to include the most recent 2.4.x HAL console. The details are described here: http://hbraun.info/2014/10/updated-management-console-in-wildfly-8-2/ Regards, Heiko _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Thu Oct 16 11:37:28 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 16 Oct 2014 10:37:28 -0500 Subject: [wildfly-dev] Console updates in trunk and 8.x In-Reply-To: <297968938.4851664.1413468632186.JavaMail.zimbra@redhat.com> References: <12341D6C-1275-4280-995E-C0944D660174@redhat.com> <297968938.4851664.1413468632186.JavaMail.zimbra@redhat.com> Message-ID: <543FE638.5010505@redhat.com> Yes, you guys have done a really nice job. Nice blog post too. On 10/16/14, 9:10 AM, Pedro Igor Silva wrote: > It really looks nice ... > > ----- Original Message ----- > From: "Heiko Braun" > To: "WildFly Dev" > Sent: Thursday, October 16, 2014 11:06:52 AM > Subject: [wildfly-dev] Console updates in trunk and 8.x > > > > We've updated trunk and 8.x to include the most recent 2.4.x HAL console. The details are described here: > > http://hbraun.info/2014/10/updated-management-console-in-wildfly-8-2/ > > Regards, Heiko > > _______________________________________________ > 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Thu Oct 16 11:45:06 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 16 Oct 2014 10:45:06 -0500 Subject: [wildfly-dev] Console updates in trunk and 8.x In-Reply-To: <12341D6C-1275-4280-995E-C0944D660174@redhat.com> References: <12341D6C-1275-4280-995E-C0944D660174@redhat.com> Message-ID: Very cool. I would like to aggregate this on the wildfly site, perhaps at the time of release? On Oct 16, 2014, at 9:06 AM, Heiko Braun wrote: > > > We've updated trunk and 8.x to include the most recent 2.4.x HAL console. The details are described here: > > http://hbraun.info/2014/10/updated-management-console-in-wildfly-8-2/ > > Regards, Heiko > _______________________________________________ > 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 anmiller at redhat.com Thu Oct 16 13:57:54 2014 From: anmiller at redhat.com (Andrig T. Miller) Date: Thu, 16 Oct 2014 13:57:54 -0400 (EDT) Subject: [wildfly-dev] Console updates in trunk and 8.x In-Reply-To: <12341D6C-1275-4280-995E-C0944D660174@redhat.com> References: <12341D6C-1275-4280-995E-C0944D660174@redhat.com> Message-ID: <10172427.3591.1413482271249.JavaMail.andrigtmiller@worklaptop.miller.org> Very nice! Congratulations! Andy ----- Original Message ----- > From: "Heiko Braun" > To: "WildFly Dev" > Sent: Thursday, October 16, 2014 8:06:52 AM > Subject: [wildfly-dev] Console updates in trunk and 8.x > We've updated trunk and 8.x to include the most recent 2.4.x HAL > console. The details are described here: > http://hbraun.info/2014/10/updated-management-console-in-wildfly-8-2/ > Regards, Heiko > _______________________________________________ > 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/20141016/cb0c818f/attachment.html From arun.gupta at gmail.com Thu Oct 16 13:58:06 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 16 Oct 2014 10:58:06 -0700 Subject: [wildfly-dev] WebSocket session.getOpenSession returning 0 on JavaFX client Message-ID: Trying to create a simple sample to emulate Google Docs using WebSocket. Server is deployed on WildFly 8.1.0 and client is using JavaFX. The code is at: https://github.com/javaee-samples/javaee7-samples/tree/master/websocket/google-docs session.getOpenSessions() on client is always returning 0 size hashset. Any idea ? Arun -- http://blog.arungupta.me http://twitter.com/arungupta From claudio at claudius.com.br Thu Oct 16 23:46:13 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Fri, 17 Oct 2014 00:46:13 -0300 Subject: [wildfly-dev] status attribute for datasources Message-ID: Hi, what do you think of adding a "status" attribute for datasources ? It should have the same meaning of "status" for deployment. The deployment have the status attribute, that says if the application was properly deployed and is running. /deployment=jboss-kitchensink.war:read-attribute(name=status) { "outcome" => "success", "result" => "FAILED" } However there is no way in CLI mode to ask if a datasource (RA also) is working, user must check for exceptions in the log. The proposal is to add an attribute status to a datasource and RA, it will be true if test-connection-in-pool returns true, otherwise false. Every moment the datasource configuration changes, a test-connection is performed. I came to this suggestion, as was working for a customer that has 16 datasources (they are migrating from weblogic) and there were some connections errors, but the user was unable to see at once which connections failed, they needed to grep log. It would be very useful to have this attribute. Kind regards -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From claudio at claudius.com.br Fri Oct 17 00:04:14 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Fri, 17 Oct 2014 01:04:14 -0300 Subject: [wildfly-dev] HAL: show deployment status Message-ID: Hi, on deployment view, it shows the "enabled" attribute for deployments, but if the deploy failed for some reason (status=false) the user only sees the 404 http error code when he tries to access the application. Also the "ok" mark (icon) on the deploy view, lead to user think the deploy was ok I propose to add the deploy "status" attribute besides the "enabled" attribute, but only if the status is failed. An example http://imgur.com/WhrzewT I know the image is horrible, but it shows the proposal. It is important to show it in the list view and not in the attribute list below them, because the failed deployments should be quickly visible in web console. -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From hbraun at redhat.com Fri Oct 17 03:47:19 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 17 Oct 2014 09:47:19 +0200 Subject: [wildfly-dev] status attribute for datasources In-Reply-To: References: Message-ID: Doesn't the enabled attribute serve the same purpose? Ort do I miss something? On 17 Oct 2014, at 05:46, Claudio Miranda wrote: > Hi, what do you think of adding a "status" attribute for datasources ? > It should have the same meaning of "status" for deployment. > > The deployment have the status attribute, that says if the application > was properly deployed and is running. > > /deployment=jboss-kitchensink.war:read-attribute(name=status) > { > "outcome" => "success", > "result" => "FAILED" > } > > However there is no way in CLI mode to ask if a datasource (RA also) > is working, user must check for exceptions in the log. > > The proposal is to add an attribute status to a datasource and RA, it > will be true if test-connection-in-pool returns true, otherwise false. > Every moment the datasource configuration changes, a test-connection > is performed. > > I came to this suggestion, as was working for a customer that has 16 > datasources (they are migrating from weblogic) and there were some > connections errors, but the user was unable to see at once which > connections failed, they needed to grep log. It would be very useful > to have this attribute. > > > 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 From hbraun at redhat.com Fri Oct 17 03:47:58 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 17 Oct 2014 09:47:58 +0200 Subject: [wildfly-dev] HAL: show deployment status In-Reply-To: References: Message-ID: Makes sense to me. Can you file a Jira for this? On 17 Oct 2014, at 06:04, Claudio Miranda wrote: > Hi, on deployment view, it shows the "enabled" attribute for > deployments, but if the deploy failed for some reason (status=false) > the user only sees the 404 http error code when he tries to access the > application. > > Also the "ok" mark (icon) on the deploy view, lead to user think the > deploy was ok > > I propose to add the deploy "status" attribute besides the "enabled" > attribute, but only if the status is failed. An example > > http://imgur.com/WhrzewT > > I know the image is horrible, but it shows the proposal. It is > important to show it in the list view and not in the attribute list > below them, because the failed deployments should be quickly visible > in web console. > > -- > 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 From lponce at redhat.com Fri Oct 17 03:49:02 2014 From: lponce at redhat.com (Lucas Ponce) Date: Fri, 17 Oct 2014 03:49:02 -0400 (EDT) Subject: [wildfly-dev] WebSocket session.getOpenSession returning 0 on JavaFX client In-Reply-To: References: Message-ID: <4073995.10579914.1413532142032.JavaMail.zimbra@redhat.com> Hi Arun, I am working on a JIRA related to WebSocket for Undertow, I can investigate if there is no one looking on it. Lucas ----- Mensaje original ----- > De: "Arun Gupta" > Para: "WildFly Dev" > Enviados: Jueves, 16 de Octubre 2014 19:58:06 > Asunto: [wildfly-dev] WebSocket session.getOpenSession returning 0 on JavaFX client > > Trying to create a simple sample to emulate Google Docs using > WebSocket. Server is deployed on WildFly 8.1.0 and client is using > JavaFX. The code is at: > > https://github.com/javaee-samples/javaee7-samples/tree/master/websocket/google-docs > > session.getOpenSessions() on client is always returning 0 size hashset. > > Any idea ? > > Arun > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From claudio at claudius.com.br Fri Oct 17 09:03:18 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Fri, 17 Oct 2014 10:03:18 -0300 Subject: [wildfly-dev] status attribute for datasources In-Reply-To: References: Message-ID: On Fri, Oct 17, 2014 at 4:47 AM, Heiko Braun wrote: > Doesn't the enabled attribute serve the same purpose? Ort do I miss something? The enabled attribute sets the datasource to start at boot time. If you provoke an error in the datasource settings, the connection stays in error state but there is no indicator in the datasource CLI. -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From claudio at claudius.com.br Fri Oct 17 09:18:20 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Fri, 17 Oct 2014 10:18:20 -0300 Subject: [wildfly-dev] HAL: show deployment status In-Reply-To: References: Message-ID: On Fri, Oct 17, 2014 at 4:47 AM, Heiko Braun wrote: > Makes sense to me. Can you file a Jira for this? HAL-512. May I work on this ? -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From arun.gupta at gmail.com Fri Oct 17 09:21:06 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Fri, 17 Oct 2014 06:21:06 -0700 Subject: [wildfly-dev] WebSocket session.getOpenSession returning 0 on JavaFX client In-Reply-To: <4073995.10579914.1413532142032.JavaMail.zimbra@redhat.com> References: <4073995.10579914.1413532142032.JavaMail.zimbra@redhat.com> Message-ID: It'll be great if you can look at it. I'd like to showcase this sample in my talk next week :) Arun On Fri, Oct 17, 2014 at 12:49 AM, Lucas Ponce wrote: > Hi Arun, > > I am working on a JIRA related to WebSocket for Undertow, I can investigate if there is no one looking on it. > > Lucas > > ----- Mensaje original ----- >> De: "Arun Gupta" >> Para: "WildFly Dev" >> Enviados: Jueves, 16 de Octubre 2014 19:58:06 >> Asunto: [wildfly-dev] WebSocket session.getOpenSession returning 0 on JavaFX client >> >> Trying to create a simple sample to emulate Google Docs using >> WebSocket. Server is deployed on WildFly 8.1.0 and client is using >> JavaFX. The code is at: >> >> https://github.com/javaee-samples/javaee7-samples/tree/master/websocket/google-docs >> >> session.getOpenSessions() on client is always returning 0 size hashset. >> >> Any idea ? >> >> Arun >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- http://blog.arungupta.me http://twitter.com/arungupta From hbraun at redhat.com Fri Oct 17 10:02:55 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 17 Oct 2014 16:02:55 +0200 Subject: [wildfly-dev] HAL: show deployment status In-Reply-To: References: Message-ID: Yes, of course. We appreciate it ;) > Am 17.10.2014 um 15:18 schrieb Claudio Miranda : > >> On Fri, Oct 17, 2014 at 4:47 AM, Heiko Braun wrote: >> Makes sense to me. Can you file a Jira for this? > > HAL-512. May I work on this ? > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br From claudio at claudius.com.br Fri Oct 17 15:10:08 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Fri, 17 Oct 2014 16:10:08 -0300 Subject: [wildfly-dev] status attribute for datasources In-Reply-To: References: Message-ID: On Fri, Oct 17, 2014 at 10:03 AM, Claudio Miranda wrote: > The enabled attribute sets the datasource to start at boot time. > If you provoke an error in the datasource settings, the connection > stays in error state but there is no indicator in the datasource CLI. What do you think ? May I open an issue for this ? -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From brian.stansberry at redhat.com Fri Oct 17 16:16:53 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 17 Oct 2014 15:16:53 -0500 Subject: [wildfly-dev] status attribute for datasources In-Reply-To: References: Message-ID: <54417935.4070607@redhat.com> You need buy-in from the JCA team, as they are the ones who'd need to accept the server-side change. AIUI your proposal is that any config change that effects a ds resource would trigger an automatic connection test, with this attribute set to the result. That's 95%+ of the work. Exposing the attribute value in the console is the trivial part. On 10/17/14, 2:10 PM, Claudio Miranda wrote: > On Fri, Oct 17, 2014 at 10:03 AM, Claudio Miranda > wrote: >> The enabled attribute sets the datasource to start at boot time. >> If you provoke an error in the datasource settings, the connection >> stays in error state but there is no indicator in the datasource CLI. > > What do you think ? May I open an issue for this ? > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From claudio at claudius.com.br Sat Oct 18 09:15:30 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Sat, 18 Oct 2014 10:15:30 -0300 Subject: [wildfly-dev] HAL: show deployment status In-Reply-To: References: Message-ID: On Fri, Oct 17, 2014 at 1:04 AM, Claudio Miranda wrote: > I propose to add the deploy "status" attribute besides the "enabled" > attribute, but only if the status is failed. An example The functionality was already implemented, but not working https://github.com/hal/core/blob/master/gui/src/main/java/org/jboss/as/console/client/shared/deployment/DeploymentTreeModel.java#L102 Because the DeploymentRecord status attribute was not populated, it always returned an empty string. To work, include-runtime=true must be added to the list deployment operation https://github.com/hal/core/blob/master/gui/src/main/java/org/jboss/as/console/client/shared/deployment/DeploymentStore.java#L219 I will do PR today after some tests. -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From manderse at redhat.com Sun Oct 19 02:48:56 2014 From: manderse at redhat.com (Max Rydahl Andersen) Date: Sun, 19 Oct 2014 08:48:56 +0200 Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log manager to be org.jboss.logmanager.LogManager Message-ID: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com> Heya, In tools and around arquillian I'm seeing more and more of $subject error that I can't figure out the cause of. I've found https://issues.jboss.org/browse/WFLY-3152 which David responds the error message is clear. I might be clear, but I can't figure out why starting wildfly the exact same way will in one case result in this error but then on second start it just works. I first thought that our tools might not be setting the LogManager (which it does not), but when I look at standalone.sh in the same server there is also no setting of this property hence afaics the server is being obtuse. The answer in all cases seem to have been "have tried restarting it?" and then things starts working, until it doesn't - and then we restart again. Any idea on what is going on here ? Thanks, /max http://about.me/maxandersen From stuart.w.douglas at gmail.com Sun Oct 19 03:42:29 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Sun, 19 Oct 2014 18:42:29 +1100 Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log manager to be org.jboss.logmanager.LogManager In-Reply-To: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com> References: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com> Message-ID: <54436B65.6060607@gmail.com> Are you using a java agent by any chance? If you are then the java agent is probably causing the issue, by attempting to log something before JBoss modules can set the log manager. If you are not using a java agent then I am not sure exactly what the cause might be. Looking at the code it looks like it is possible for a custom security manager to break logging as the security manager is initialized first, however that does not seem likely. Can you share the details on exactly what command line is being used to start the server? Stuart Max Rydahl Andersen wrote: > Heya, > > In tools and around arquillian I'm seeing more and more of $subject > error that I can't figure out the cause of. > > I've found https://issues.jboss.org/browse/WFLY-3152 which David > responds the error message is clear. > > I might be clear, but I can't figure out why starting wildfly the exact > same way will in one case result in this > error but then on second start it just works. > > I first thought that our tools might not be setting the LogManager > (which it does not), but when I look at standalone.sh > in the same server there is also no setting of this property hence > afaics the server is being obtuse. > > The answer in all cases seem to have been "have tried restarting it?" > and then things starts working, until it doesn't - and > then we restart again. > > Any idea on what is going on here ? > > Thanks, > /max > http://about.me/maxandersen > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jperkins at redhat.com Sun Oct 19 19:48:54 2014 From: jperkins at redhat.com (James R. Perkins) Date: Sun, 19 Oct 2014 16:48:54 -0700 Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log manager to be org.jboss.logmanager.LogManager In-Reply-To: <54436B65.6060607@gmail.com> References: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com> <54436B65.6060607@gmail.com> Message-ID: <54444DE6.3000705@redhat.com> As Stuart asked more details would help. The only way this could happen is if something, an agent for example, attempts to get a logger before JBoss Modules initializes logging. JBoss Modules looks for a META-INF/services/ java.util.logging.LogManager service which JBoss Log Manager has. If an agent needs to be used the java.util.logging.manager needs to be set to org.jboss.logmanager.LogManager before the agent initializes a logger. On 10/19/2014 12:42 AM, Stuart Douglas wrote: > Are you using a java agent by any chance? > > If you are then the java agent is probably causing the issue, by > attempting to log something before JBoss modules can set the log manager. > > If you are not using a java agent then I am not sure exactly what the > cause might be. Looking at the code it looks like it is possible for a > custom security manager to break logging as the security manager is > initialized first, however that does not seem likely. > > Can you share the details on exactly what command line is being used to > start the server? > > Stuart > > Max Rydahl Andersen wrote: >> Heya, >> >> In tools and around arquillian I'm seeing more and more of $subject >> error that I can't figure out the cause of. >> >> I've found https://issues.jboss.org/browse/WFLY-3152 which David >> responds the error message is clear. >> >> I might be clear, but I can't figure out why starting wildfly the exact >> same way will in one case result in this >> error but then on second start it just works. >> >> I first thought that our tools might not be setting the LogManager >> (which it does not), but when I look at standalone.sh >> in the same server there is also no setting of this property hence >> afaics the server is being obtuse. >> >> The answer in all cases seem to have been "have tried restarting it?" >> and then things starts working, until it doesn't - and >> then we restart again. >> >> Any idea on what is going on here ? >> >> Thanks, >> /max >> http://about.me/maxandersen >> _______________________________________________ >> 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 -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141019/28802281/attachment.html From hbraun at redhat.com Mon Oct 20 03:25:25 2014 From: hbraun at redhat.com (Heiko Braun) Date: Mon, 20 Oct 2014 09:25:25 +0200 Subject: [wildfly-dev] status attribute for datasources In-Reply-To: <54417935.4070607@redhat.com> References: <54417935.4070607@redhat.com> Message-ID: <0B8722EE-75E0-4E82-8F2E-D99667B91EAB@redhat.com> +1 @stefano Can you comment on this proposal? On 17 Oct 2014, at 22:16, Brian Stansberry wrote: > You need buy-in from the JCA team, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141020/0a02b1bb/attachment.html From tdiesler at redhat.com Mon Oct 20 04:48:26 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Mon, 20 Oct 2014 10:48:26 +0200 Subject: [wildfly-dev] jboss/wildfly docker image does not use tags Message-ID: <60E2B731-16AE-4A66-97E6-AA87892CF631@redhat.com> Folks, I recently started to look at jboss/wildfly and noticed that this does not use tags. As a consequence, any image that build of jboss/wildfly is subject to breakage when there is an update of this repo. I suggest to also provide tagged versions of these images similar to this . cheers ?thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141020/f453fe8e/attachment.html From manderse at redhat.com Mon Oct 20 05:20:22 2014 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 20 Oct 2014 11:20:22 +0200 Subject: [wildfly-dev] JBAS011592 the logging subsystem requires the log manager to be org.jboss.logmanager.LogManager In-Reply-To: <54444DE6.3000705@redhat.com> References: <8619BFE7-73A8-414A-A1C7-9B3E0DBFC410@redhat.com> <54436B65.6060607@gmail.com> <54444DE6.3000705@redhat.com> Message-ID: <513BC043-2599-40A9-8C28-6574B29929C1@redhat.com> On 20 Oct 2014, at 1:48, James R. Perkins wrote: > As Stuart asked more details would help. > > The only way this could happen is if something, an agent for example, > attempts to get a logger before JBoss Modules initializes logging. > JBoss Modules looks for a META-INF/services/ > java.util.logging.LogManager service which JBoss Log Manager has. If > an agent needs to be used the java.util.logging.manager needs to be > set to org.jboss.logmanager.LogManager before the agent initializes a > logger. It is all in the jira. And no, these errors have been happening on what is just plain vanilla WildFly or EAP/JPP bundles. We do not do any agent funkyness afaik. And as said the "workaround" so far have been "restart it" and it works. zero changes to the state or arguments. /max > > On 10/19/2014 12:42 AM, Stuart Douglas wrote: >> Are you using a java agent by any chance? >> >> If you are then the java agent is probably causing the issue, by >> attempting to log something before JBoss modules can set the log >> manager. >> >> If you are not using a java agent then I am not sure exactly what the >> cause might be. Looking at the code it looks like it is possible for >> a >> custom security manager to break logging as the security manager is >> initialized first, however that does not seem likely. >> >> Can you share the details on exactly what command line is being used >> to >> start the server? >> >> Stuart >> >> Max Rydahl Andersen wrote: >>> Heya, >>> >>> In tools and around arquillian I'm seeing more and more of $subject >>> error that I can't figure out the cause of. >>> >>> I've found https://issues.jboss.org/browse/WFLY-3152 which David >>> responds the error message is clear. >>> >>> I might be clear, but I can't figure out why starting wildfly the >>> exact >>> same way will in one case result in this >>> error but then on second start it just works. >>> >>> I first thought that our tools might not be setting the LogManager >>> (which it does not), but when I look at standalone.sh >>> in the same server there is also no setting of this property hence >>> afaics the server is being obtuse. >>> >>> The answer in all cases seem to have been "have tried restarting >>> it?" >>> and then things starts working, until it doesn't - and >>> then we restart again. >>> >>> Any idea on what is going on here ? >>> >>> Thanks, >>> /max >>> http://about.me/maxandersen >>> _______________________________________________ >>> 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 > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev /max http://about.me/maxandersen From jai.forums2013 at gmail.com Mon Oct 20 05:26:31 2014 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 20 Oct 2014 14:56:31 +0530 Subject: [wildfly-dev] smoke testing failure In-Reply-To: References: <17398798.5184.1413263981421.JavaMail.joe@localhost.localdomain> Message-ID: <5444D547.2000008@gmail.com> Saw the same issue locally and from what I see in that testcase, it doesn't appear to be a JVM vendor/version issue. This actually is a race condition in the test method execution and removal of content from content repository. That ServerInModuleDeploymentTestCase testcase has multiple test methods which deal with deploying and undeploying. From what I am observing it looks like one of the test methods first runs (I guess the testDeploymentFileApi) and does its deploy/undeploy sequence and then the testDeploymentStreamApi runs which first does a file listing of the content directory and turns out the undeploy operation from the previous test method hasn't yet removed the content from the content repository yet. So this test picks up those (to be deleted) hashes as initial hashes in the content repo. While this test method is running, a background thread cleans up previously undeployed the hashes from the content repository. As a result a subsequent file listing of the content directory from this current test method doesn't find those expected initial hashes. I'm not sure what the expected behaviour of a undeploy operation is - whether the undeploy should complete only after the content has been removed (probably not) from the content repository or whether it can return before that (as it seems to be happening now). FWIW, here's my environment details: java version "1.7.0_15" Java(TM) SE Runtime Environment (build 1.7.0_15-b03) Java HotSpot(TM) Server VM (build 23.7-b01, mixed mode) Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.618 sec <<< FAILURE! - in org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase testDeploymentStreamApi(org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase) Time elapsed: 0.473 sec <<< FAILURE! java.lang.AssertionError: expected:<[29c4c47c1224a00169a8df02d84c3d6ff014b5fb, b9227c99efad4b615df0ad5288b6690216ed7bad]> but was:<[29c4c47c1224a00169a8df02d84c3d6ff014b5fb]> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.junit.Assert.assertEquals(Assert.java:144) at org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeployments(ServerInModuleDeploymentTestCase.java:618) at org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeploymentStreamApi(ServerInModuleDeploymentTestCase.java:96) -Jaikiran On Wednesday 15 October 2014 06:28 PM, Eduardo Sant?Ana da Silva wrote: > Could be some change regarding some message digest used on ShrinkWrap > API based upon a different JVM version? > > Just a guess... > > --- > Eduardo Sant'Ana da Silva > > 2014-10-15 1:40 GMT-03:00 Peter Cai >: > > Well, I have no luck on tracking down what is happening in this > test case. > But things is becoming more interesting. > I can partially repeat the failure on Windows 8. > Now, on both Ubuntu 14.04 and Windows 8, using JVM 1.7.0_51, > run the test from the smoke testing module. i.e., > cd testsuite\integration\smoke > mvn clean test > -Dtest=org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase > Interestingly, this testcase sometimes passes, sometimes fails. > When failed, with the following info: > Failed tests: > ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 > expected:<[504917ff8990a5f90995d412117e39afbdaf6747]> but was:<[]> > Regards, > Peter > > On Tue, Oct 14, 2014 at 10:33 PM, Peter Cai > wrote: > > On my side, I use "mvn -fae -Dmaven.test.failure.ignore=true > clean install", this test mentioned above is the only test > that failed. > > I am trying to track it down. > > Regards, > Peter > > On Tue, Oct 14, 2014 at 7:23 PM, Tomaz( Cerar > > wrote: > > Guys, is problem only this test or also something else? > > it is possible that this tests has problems that makes it > fail on certain scenarios. > > Any chance anyone of you that can reproduce it, can try to > track it down what the issue is? > > if you add "-fae -Dmaven.test.failure.ignore=true " as > param to build, it will continue building/testing after > test failure(s), > so you can see what all tests fail for you or only this one. > > On Tue, Oct 14, 2014 at 7:19 AM, Edward Wertz > > wrote: > > I've gotten that error for a while, so you're not > alone, but haven't been able to track it down either, > so I'm not much help fixing it. Java/Maven versions > don't effect it and I can build fine on my Windows 7 > machine. It's a mystery to me what's causing it. > > Linux localhost.localdomain 3.16.2-201.fc20.x86_64 #1 > SMP Mon Sep 15 19:57:50 UTC 2014 x86_64 x86_64 x86_64 > GNU/Linux > LSB Version: > :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch > Distributor ID: Fedora > Description: Fedora release 20 (Heisenbug) > Release: 20 > Codename: Heisenbug > > Joe Wertz > > > ----- Original Message ----- > > From: "Eduardo Sant?Ana da Silva" > > > > To: "Peter Cai" > > > Cc: wildfly-dev at lists.jboss.org > > > Sent: Tuesday, October 14, 2014 8:29:11 AM > > Subject: Re: [wildfly-dev] smoke testing failure > > > > > > > > I've made the build successfully on the following > environment as > > well: > > > > OS X 10.9.5 > > java version "1.8.0_05" > > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, > mixed mode) > > > > > > 2014-10-13 20:19 GMT-03:00 Peter Cai < > qutpeter at gmail.com > : > > > > It should be some environmental issue. > > I can successfully run the smoke test on Windows 8, > > > > And the JVM is: > > java version "1.7.0_51" > > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, > mixed mode) > > > > Regards > > > > > > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai < > qutpeter at gmail.com > > > wrote: > > > > > > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP > Thu May 15 18:06:16 > > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu > 14.04 desktop) > > > > JVM: > > java version "1.7.0_51" > > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, > mixed mode) > > > > My guess is environmental issue as well. But can't > find anything so > > far. > > > > Regards, > > > > Peter > > > > > > On Mon, Oct 13, 2014 at 8:29 PM, Tomaz( Cerar < > tomaz.cerar at gmail.com > > > wrote: > > > > os? jvm? arch? > > > > looking at our nightly jobs whole testsuite passes > on our CI with > > JDK7 & 8 on windows and on linux. > > > > I am guessing it must be environmental issue. > > > > > > On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai < > qutpeter at gmail.com > > > wrote: > > > > Hi, > > > > It looks like that the current HEAD of Wildfly will > failed when > > running smoke testing with the following information: > > > > Results : > > > > Failed tests: > > > ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 > > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, > > 342ae7aec9bff370e3de8704ed9642a718986e61]> but > > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> > > > > Any cues? > > > > Regards, > > > > _______________________________________________ > > 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 > > > > > > > > -- > > > > > > ________________ __________ > > > > > > Eduardo Sant'Ana da Silva - Dr. > > Pesquisador / Consultor de TI > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > > > > _______________________________________________ > 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/20141020/63968fa6/attachment-0001.html From tdiesler at redhat.com Mon Oct 20 06:09:09 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Mon, 20 Oct 2014 12:09:09 +0200 Subject: [wildfly-dev] jboss/wildfly docker image does not use tags In-Reply-To: <60E2B731-16AE-4A66-97E6-AA87892CF631@redhat.com> References: <60E2B731-16AE-4A66-97E6-AA87892CF631@redhat.com> Message-ID: <3067CA3C-5352-4DEC-9BF3-08E19212EC69@redhat.com> Tracked by: https://issues.jboss.org/browse/WFLY-3996 > On 20 Oct 2014, at 10:48, Thomas Diesler wrote: > > Folks, > > I recently started to look at jboss/wildfly and noticed that this does not use tags. As a consequence, any image that build of jboss/wildfly is subject to breakage when there is an update of this repo. I suggest to also provide tagged versions of these images similar to this . > > 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/20141020/d773c3c3/attachment.html From david.lloyd at redhat.com Mon Oct 20 08:48:39 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 20 Oct 2014 07:48:39 -0500 Subject: [wildfly-dev] About last week's core release... Message-ID: <544504A7.5050802@redhat.com> Last Friday I prepared the wildfly-core 1.0.0.Alpha10 release. It's in a staging repo up on Nexus right now - however, Brontes was down (as was the entire Brno data center, due to maintenance, I hear) so I was unable to do a clean test of WildFly with the updated core, thus the release hasn't happened. We'll shoot for early this week. If however the testing fails, then there will likely be no "last week" release, and instead we'll try again this Friday. -- - DML From mgoldman at redhat.com Mon Oct 20 09:09:23 2014 From: mgoldman at redhat.com (Marek Goldmann) Date: Mon, 20 Oct 2014 15:09:23 +0200 Subject: [wildfly-dev] jboss/wildfly docker image does not use tags In-Reply-To: <60E2B731-16AE-4A66-97E6-AA87892CF631@redhat.com> References: <60E2B731-16AE-4A66-97E6-AA87892CF631@redhat.com> Message-ID: <1413810563.4357.10@smtp.corp.redhat.com> // Resending to all Thomas, It was not possible to use tags in the previous set up where we had all our dockerfiles in one repository. Now I'm in the process of moving them to their own repos under: https://github.com/jboss-dockerfiles/ Tags will be added at some point (the lack of tags triggered the move, btw). --Marek On pon, pa? 20, 2014 at 10:48 , Thomas Diesler wrote: > Folks, > > I recently started to look at jboss/wildfly and noticed that this > does not use tags. As a consequence, any image that build of > jboss/wildfly is subject to breakage when there is an update of this > repo. I suggest to also provide tagged versions of these images > similar to this. > > cheers > ?thomas From nono_du_31 at hotmail.fr Mon Oct 20 09:49:16 2014 From: nono_du_31 at hotmail.fr (weedfly) Date: Mon, 20 Oct 2014 06:49:16 -0700 (PDT) Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> Message-ID: <1413812956667-5715140.post@n5.nabble.com> Hi guys Can you please tell me if the support for notifications is embedded in wildfly 81.0-Final ?* I'm migrating an ear from 4.3EAP to wildfly and my application relies on startup stop jmx notifications to start some treatments. As a result, my application does not run correctly because of the absence of this feature. Could you please suggest me an alternative supplied by widfly to solve my problem ? thank you -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/Proposal-to-add-notifications-to-WildFly-management-model-and-API-tp5714484p5715140.html Sent from the WildFly Development mailing list archive at Nabble.com. From jesper.pedersen at redhat.com Mon Oct 20 10:02:18 2014 From: jesper.pedersen at redhat.com (Jesper Pedersen) Date: Mon, 20 Oct 2014 10:02:18 -0400 Subject: [wildfly-dev] status attribute for datasources In-Reply-To: References: Message-ID: <544515EA.30900@redhat.com> On 10/16/2014 11:46 PM, Claudio Miranda wrote: > Hi, what do you think of adding a "status" attribute for datasources ? > It should have the same meaning of "status" for deployment. > > The deployment have the status attribute, that says if the application > was properly deployed and is running. > > /deployment=jboss-kitchensink.war:read-attribute(name=status) > { > "outcome" => "success", > "result" => "FAILED" > } > > However there is no way in CLI mode to ask if a datasource (RA also) > is working, user must check for exceptions in the log. > > The proposal is to add an attribute status to a datasource and RA, it > will be true if test-connection-in-pool returns true, otherwise false. > Every moment the datasource configuration changes, a test-connection > is performed. > > I came to this suggestion, as was working for a customer that has 16 > datasources (they are migrating from weblogic) and there were some > connections errors, but the user was unable to see at once which > connections failed, they needed to grep log. It would be very useful > to have this attribute. > :test-connection-in-pool may require credentials, so it will only be 'automatic' in some cases. You could do your own 'extension' on top of the :test-connection-in-pool though. HTH. Best regards, Jesper From jmesnil at redhat.com Mon Oct 20 10:14:51 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Mon, 20 Oct 2014 16:14:51 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <1413812956667-5715140.post@n5.nabble.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <1413812956667-5715140.post@n5.nabble.com> Message-ID: Support for WildFly notifications has been backported to 8.2.0.CR1. It is not in 8.1.0.Final. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From nono_du_31 at hotmail.fr Mon Oct 20 10:22:39 2014 From: nono_du_31 at hotmail.fr (weedfly) Date: Mon, 20 Oct 2014 07:22:39 -0700 (PDT) Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <1413812956667-5715140.post@n5.nabble.com> Message-ID: <1413814959316-5715143.post@n5.nabble.com> Thank you for the quick response. I know it is not the right place to talk about it but where can i find this version ? It did not appears on download section of the website ? Best regards -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/Proposal-to-add-notifications-to-WildFly-management-model-and-API-tp5714484p5715143.html Sent from the WildFly Development mailing list archive at Nabble.com. From tomaz.cerar at gmail.com Mon Oct 20 10:32:48 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 20 Oct 2014 07:32:48 -0700 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API Message-ID: <1529192983792994670@unknownmsgid> On github. Branch 8.x. It is not released yet. But you can try with 9.0.0.Alpha1 which also has notifications. Sent from my PhoneFrom: weedfly Sent: ?20.?10.?2014 16:23 To: wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] Proposal to add notifications to WildFly management model and API Thank you for the quick response. I know it is not the right place to talk about it but where can i find this version ? It did not appears on download section of the website ? Best regards -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/Proposal-to-add-notifications-to-WildFly-management-model-and-API-tp5714484p5715143.html Sent from the WildFly Development mailing list archive at Nabble.com. _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From claudio at claudius.com.br Mon Oct 20 11:45:32 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Mon, 20 Oct 2014 13:45:32 -0200 Subject: [wildfly-dev] status attribute for datasources In-Reply-To: <544515EA.30900@redhat.com> References: <544515EA.30900@redhat.com> Message-ID: On Mon, Oct 20, 2014 at 12:02 PM, Jesper Pedersen wrote: > :test-connection-in-pool may require credentials, so it will only be > 'automatic' in some cases. Hi Jesper, the purpose is to add a "status" runtime attribute to the datasource, see my initial post. Instead of call test-connection-in-pool for every datasource change, better to rely on current behavior, when application requests a new connection, the status attribute is populated accordingly to the new connection call, what do you think ? This is to improve user experience with wildfly/eap customers, to quickly see in the web console which datasources failed to open connections. ------------ What do you think of adding a "status" attribute for datasources ? It should have the same meaning of "status" for deployment. The deployment have the status attribute, that says if the application was properly deployed and is running. /deployment=jboss-kitchensink. war:read-attribute(name=status) { "outcome" => "success", "result" => "FAILED" } However there is no way in CLI mode to ask if a datasource (RA also) is working, user must check for exceptions in the log. The proposal is to add an attribute status to a datasource and RA, it will be true if test-connection-in-pool returns true, otherwise false. Every moment the datasource configuration changes, a test-connection is performed. I came to this suggestion, as was working for a customer that has 16 datasources (they are migrating from weblogic) and there were some connections errors, but the user was unable to see at once which connections failed, they needed to grep log. It would be very useful to have this attribute. -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From jesper.pedersen at redhat.com Mon Oct 20 12:56:01 2014 From: jesper.pedersen at redhat.com (Jesper Pedersen) Date: Mon, 20 Oct 2014 12:56:01 -0400 Subject: [wildfly-dev] status attribute for datasources In-Reply-To: References: <544515EA.30900@redhat.com> Message-ID: <54453EA1.7040706@redhat.com> Hi, On 10/20/2014 11:45 AM, Claudio Miranda wrote: > On Mon, Oct 20, 2014 at 12:02 PM, Jesper Pedersen > wrote: >> :test-connection-in-pool may require credentials, so it will only be >> 'automatic' in some cases. > > Hi Jesper, the purpose is to add a "status" runtime attribute to the > datasource, see my initial post. > Instead of call test-connection-in-pool for every datasource change, > better to rely on current behavior, when application requests a new > connection, the status attribute is populated accordingly to the new > connection call, what do you think ? > That is not going to happen, as testing :test-connection-in-pool per request could have a massive overhead depending on the pool status. should be used to verify an active pool. > This is to improve user experience with wildfly/eap customers, to > quickly see in the web console which datasources failed to open > connections. > Yes, I know that - but I fail to see how a 'false' value would be of benefit to the user experience even if the datasource is active and valid. Standard scenarios: pool is full (check InUse count if statistics is enabled), missing credentials (pass those in), ... I would rather see a CLI script that goes through the different scenarios that could occur and present the result. Same script could be executed from the web console, or 'hidden' behind a special "Status" field. Best regards, Jesper From sandyridgeracer at gmail.com Mon Oct 20 15:10:24 2014 From: sandyridgeracer at gmail.com (Sandeep Samdaria) Date: Tue, 21 Oct 2014 00:40:24 +0530 Subject: [wildfly-dev] Building WildFly 9.0.0.Alpha2-SNAPSHOT In-Reply-To: <543F4013.9000308@gmail.com> References: <543F4013.9000308@gmail.com> Message-ID: Hi Jaikiran, As you suggested I have picked up a JIRA from the list. I think that I can work on this issue WFLY-694 .(multi-line log output makes munging logs difficult). For the jira description, I found out that EjbJndiBindingsDeploymentUnitProcessor.java needs to be changed, which lists the JNDI Bindings. The *logBinding* function appends a new line character. I believe this hard-coded new line character needs to be replaced with a configurable property. Please let me know if this approach is correct, so that I can proceed to find a suitable solution for the same. Thanks, Sandeep. P.S. : I had posted the same on IRC, but I guess that my timing was not right as not many developers were present at that moment. On Thu, Oct 16, 2014 at 9:18 AM, Jaikiran Pai wrote: > Sandeep, > > The WFLY JIRA has some issues which have been marked as "Awaiting for > volunteers". Here's a link to such unresolved issues > https://issues.jboss.org/issues/?jql=fixVersion%20%3D%20%22Awaiting%20Volunteers%22%20AND%20project%20%3D%20WFLY%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC. > You can choose from one of them that interests you. You might want to hang > around in the #wildfly-dev channel on IRC (irc.freenode.net server) where > the WildFly developers can help you in getting started or working on the > issue that you pick. > > -Jaikiran > > On Tuesday 14 October 2014 06:08 PM, Sandeep Samdaria wrote: > > Yup, that worked for me. In addition to updating the jdk from u5 to u67, I > also had to point JAVA_HOME to the latest. > > > I wanted to contribute to wildfly project. Any minor/trivial ticket > which I can take a look into it as a newbie? > > -Sandeep. > > On Tue, Oct 14, 2014 at 2:47 PM, Toma? Cerar > wrote: > >> >> On Tue, Oct 14, 2014 at 9:28 AM, Sandeep Samdaria < >> sandyridgeracer at gmail.com> wrote: >> >>> *Java* : version "1.7.0" >>> Java(TM) SE Runtime Environment (build 1.7.0-b147) >>> Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode) >>> >> >> >> Not completely sure what is your problem, but it would start with >> updating JDK 7 to something more recent. >> you are running u5, while latest is u67 >> > > > > _______________________________________________ > wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141021/f022d093/attachment.html From stuart.w.douglas at gmail.com Mon Oct 20 17:10:32 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 21 Oct 2014 08:10:32 +1100 Subject: [wildfly-dev] Building WildFly 9.0.0.Alpha2-SNAPSHOT In-Reply-To: References: <543F4013.9000308@gmail.com> Message-ID: The approach that should be taken is the one mentioned by David, about adding support for a script consumable format that strips spaces to the logmanager project. We really don't want to just have some kind of configurable property to control the delimiter. Putting this in the management model would be massive overkill, and we don't generally go in for using random system properties to control behaviour. Also when this is desirable depends a lot on the logger that is being used. If may be that the spaces are required for the console output and not wanted for the file based logger. Stuart On Tue, Oct 21, 2014 at 6:10 AM, Sandeep Samdaria wrote: > Hi Jaikiran, > As you suggested I have picked up a JIRA from the list. I think that I can > work on this issue WFLY-694 .(multi-line > log output makes munging logs difficult). > > For the jira description, I found out that > EjbJndiBindingsDeploymentUnitProcessor.java needs to be changed, which > lists the JNDI Bindings. The *logBinding* function appends a new line > character. I believe this hard-coded new line character needs to be > replaced with a configurable property. > Please let me know if this approach is correct, so that I can proceed to > find a suitable solution for the same. > > Thanks, > Sandeep. > > P.S. : I had posted the same on IRC, but I guess that my timing was not > right as not many developers were present at that moment. > > On Thu, Oct 16, 2014 at 9:18 AM, Jaikiran Pai > wrote: > >> Sandeep, >> >> The WFLY JIRA has some issues which have been marked as "Awaiting for >> volunteers". Here's a link to such unresolved issues >> https://issues.jboss.org/issues/?jql=fixVersion%20%3D%20%22Awaiting%20Volunteers%22%20AND%20project%20%3D%20WFLY%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC. >> You can choose from one of them that interests you. You might want to hang >> around in the #wildfly-dev channel on IRC (irc.freenode.net server) >> where the WildFly developers can help you in getting started or working on >> the issue that you pick. >> >> -Jaikiran >> >> On Tuesday 14 October 2014 06:08 PM, Sandeep Samdaria wrote: >> >> Yup, that worked for me. In addition to updating the jdk from u5 to u67, >> I also had to point JAVA_HOME to the latest. >> >> >> I wanted to contribute to wildfly project. Any minor/trivial ticket >> which I can take a look into it as a newbie? >> >> -Sandeep. >> >> On Tue, Oct 14, 2014 at 2:47 PM, Toma? Cerar >> wrote: >> >>> >>> On Tue, Oct 14, 2014 at 9:28 AM, Sandeep Samdaria < >>> sandyridgeracer at gmail.com> wrote: >>> >>>> *Java* : version "1.7.0" >>>> Java(TM) SE Runtime Environment (build 1.7.0-b147) >>>> Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode) >>>> >>> >>> >>> Not completely sure what is your problem, but it would start with >>> updating JDK 7 to something more recent. >>> you are running u5, while latest is u67 >>> >> >> >> >> _______________________________________________ >> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://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/20141021/5f7e9882/attachment.html From nono_du_31 at hotmail.fr Tue Oct 21 05:19:24 2014 From: nono_du_31 at hotmail.fr (weedfly) Date: Tue, 21 Oct 2014 02:19:24 -0700 (PDT) Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <1529192983792994670@unknownmsgid> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <1529192983792994670@unknownmsgid> Message-ID: <1413883164788-5715149.post@n5.nabble.com> Oki, I tried with 9.0.0.Alpha1 but i receive only one notification (jmx attribute change) and not the start / stop notifications. I register my listener this way: final ObjectName webServerName = ObjectName.getInstance("jboss.web:service=WebServer"); LOGGER.debug("Enregistrement du listener pour le mbean jboss.web:service=WebServer"); mBeanserver.addNotificationListener(webServerName, this, null, null); LOGGER.debug("R?cup?ration du mbean jboss.system:type=Server"); final ObjectName serverName = ObjectName.getInstance("jboss.system:type=Server"); LOGGER.debug("Enregistrement du listener pour le mbean jboss.system:type=Server"); mBeanserver.addNotificationListener(serverName, this, null, null); LOGGER.info("Fin de l'initialisation du listener"); Is it still the way to do it or do wildfly supply a new API to register listeners ? Thank you for your help. -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/Proposal-to-add-notifications-to-WildFly-management-model-and-API-tp5714484p5715149.html Sent from the WildFly Development mailing list archive at Nabble.com. From rory.odonnell at oracle.com Tue Oct 21 06:13:04 2014 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 21 Oct 2014 11:13:04 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b35 and JDK 8u40 b10 are available on java.net Message-ID: <544631B0.6080309@oracle.com> Hi Guys, Early Access build for JDK 9 b35 is available on java.net, summary of changes are listed here Early Access build for JDK 8u40 b10 is available on java.net, summary of changes are listed here. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141021/3b2bb575/attachment.html From psilva at redhat.com Tue Oct 21 10:53:32 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 21 Oct 2014 10:53:32 -0400 (EDT) Subject: [wildfly-dev] Behavior of javax.servlet.ServletResponse#isCommitted In-Reply-To: <305394183.8574951.1413901773805.JavaMail.zimbra@redhat.com> Message-ID: <395451817.8592599.1413903212013.JavaMail.zimbra@redhat.com> Hi, I'm using latest build from wildfly upstream/master. Would like to know if there is an issue on how Undertow recognize that a response is already commited or not. My code is setting a header and sending an error like that response.setHeader(REQUIRES_AUTHENTICATION_HEADER_NAME, AUTHENTICATION_SCHEME_NAME); response.sendError(HttpServletResponse.SC_UNAUTHORIZED); and isCommited is always returning "false" after that. To change this behavior I have to force a flush, so isCommited returns true. Both WildFly 8.1.0.Final and EAP behave differently and isCommited returns "true" without requiring a manual flush. Is this an issue ? Regards. Pedro Igor From brian.stansberry at redhat.com Tue Oct 21 16:19:38 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 21 Oct 2014 15:19:38 -0500 Subject: [wildfly-dev] smoke testing failure In-Reply-To: <5444D547.2000008@gmail.com> References: <17398798.5184.1413263981421.JavaMail.joe@localhost.localdomain> <5444D547.2000008@gmail.com> Message-ID: <5446BFDA.9090601@redhat.com> Thanks, Jaikiran. I think this is almost certainly due to these: testFilesystemDeployment_Marker() testFilesystemDeployment_Auto() All implement the test's utility class' DeploymentExecutor.undeploy() method by deleting a file in a deployment scanner directory, and then don't wait to validate the completion of scanner execution. In each of those three the testDeployments method can return once the deployment is out of the runtime and therefore no longer visible via JMX but before the completion of the management op. The removal from the content repository is done as part of completion of the management op. (It's not a background process.) This is a problem that went undetected for years because the scanner was treating zips as non-managed deployments, and not uploading them to the content repo. That was recently changed. I think the fix is to have those DeploymentExecutor.undeploy() methods block until the .undeployed marker file appears or some reasonable timeout happens. OT: every test in this package needs to be moved to the wildfly-core testsuite. On 10/20/14, 4:26 AM, Jaikiran Pai wrote: > Saw the same issue locally and from what I see in that testcase, it > doesn't appear to be a JVM vendor/version issue. This actually is a race > condition in the test method execution and removal of content from > content repository. > > That ServerInModuleDeploymentTestCase testcase has multiple test methods > which deal with deploying and undeploying. From what I am observing it > looks like one of the test methods first runs (I guess the > testDeploymentFileApi) and does its deploy/undeploy sequence and then > the testDeploymentStreamApi runs which first does a file listing of the > content directory and turns out the undeploy operation from the previous > test method hasn't yet removed the content from the content repository > yet. So this test picks up those (to be deleted) hashes as initial > hashes in the content repo. While this test method is running, a > background thread cleans up previously undeployed the hashes from the > content repository. As a result a subsequent file listing of the content > directory from this current test method doesn't find those expected > initial hashes. > > I'm not sure what the expected behaviour of a undeploy operation is - > whether the undeploy should complete only after the content has been > removed (probably not) from the content repository or whether it can > return before that (as it seems to be happening now). > > FWIW, here's my environment details: > > java version "1.7.0_15" > Java(TM) SE Runtime Environment (build 1.7.0_15-b03) > Java HotSpot(TM) Server VM (build 23.7-b01, mixed mode) > > Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.618 > sec <<< FAILURE! - in > org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase > testDeploymentStreamApi(org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase) > Time elapsed: 0.473 sec <<< FAILURE! > java.lang.AssertionError: > expected:<[29c4c47c1224a00169a8df02d84c3d6ff014b5fb, > b9227c99efad4b615df0ad5288b6690216ed7bad]> but > was:<[29c4c47c1224a00169a8df02d84c3d6ff014b5fb]> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at > org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeployments(ServerInModuleDeploymentTestCase.java:618) > at > org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeploymentStreamApi(ServerInModuleDeploymentTestCase.java:96) > > > -Jaikiran > On Wednesday 15 October 2014 06:28 PM, Eduardo Sant?Ana da Silva wrote: >> Could be some change regarding some message digest used on ShrinkWrap >> API based upon a different JVM version? >> >> Just a guess... >> >> --- >> Eduardo Sant'Ana da Silva >> >> 2014-10-15 1:40 GMT-03:00 Peter Cai > >: >> >> Well, I have no luck on tracking down what is happening in this >> test case. >> But things is becoming more interesting. >> I can partially repeat the failure on Windows 8. >> Now, on both Ubuntu 14.04 and Windows 8, using JVM 1.7.0_51, >> run the test from the smoke testing module. i.e., >> cd testsuite\integration\smoke >> mvn clean test >> -Dtest=org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase >> Interestingly, this testcase sometimes passes, sometimes fails. >> When failed, with the following info: >> Failed tests: >> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 >> expected:<[504917ff8990a5f90995d412117e39afbdaf6747]> but was:<[]> >> Regards, >> Peter >> >> On Tue, Oct 14, 2014 at 10:33 PM, Peter Cai > > wrote: >> >> On my side, I use "mvn -fae -Dmaven.test.failure.ignore=true >> clean install", this test mentioned above is the only test >> that failed. >> >> I am trying to track it down. >> >> Regards, >> Peter >> >> On Tue, Oct 14, 2014 at 7:23 PM, Toma? Cerar >> > wrote: >> >> Guys, is problem only this test or also something else? >> >> it is possible that this tests has problems that makes it >> fail on certain scenarios. >> >> Any chance anyone of you that can reproduce it, can try to >> track it down what the issue is? >> >> if you add "-fae -Dmaven.test.failure.ignore=true " as >> param to build, it will continue building/testing after >> test failure(s), >> so you can see what all tests fail for you or only this one. >> >> On Tue, Oct 14, 2014 at 7:19 AM, Edward Wertz >> > wrote: >> >> I've gotten that error for a while, so you're not >> alone, but haven't been able to track it down either, >> so I'm not much help fixing it. Java/Maven versions >> don't effect it and I can build fine on my Windows 7 >> machine. It's a mystery to me what's causing it. >> >> Linux localhost.localdomain 3.16.2-201.fc20.x86_64 #1 >> SMP Mon Sep 15 19:57:50 UTC 2014 x86_64 x86_64 x86_64 >> GNU/Linux >> LSB Version: >> :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch >> Distributor ID: Fedora >> Description: Fedora release 20 (Heisenbug) >> Release: 20 >> Codename: Heisenbug >> >> Joe Wertz >> >> >> ----- Original Message ----- >> > From: "Eduardo Sant?Ana da Silva" >> > > >> > To: "Peter Cai" > > >> > Cc: wildfly-dev at lists.jboss.org >> >> > Sent: Tuesday, October 14, 2014 8:29:11 AM >> > Subject: Re: [wildfly-dev] smoke testing failure >> > >> > >> > >> > I've made the build successfully on the following >> environment as >> > well: >> > >> > OS X 10.9.5 >> > java version "1.8.0_05" >> > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >> > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, >> mixed mode) >> > >> > >> > 2014-10-13 20:19 GMT-03:00 Peter Cai < >> qutpeter at gmail.com > : >> > >> > It should be some environmental issue. >> > I can successfully run the smoke test on Windows 8, >> > >> > And the JVM is: >> > java version "1.7.0_51" >> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, >> mixed mode) >> > >> > Regards >> > >> > >> > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai < >> qutpeter at gmail.com > >> > wrote: >> > >> > >> > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP >> Thu May 15 18:06:16 >> > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu >> 14.04 desktop) >> > >> > JVM: >> > java version "1.7.0_51" >> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, >> mixed mode) >> > >> > My guess is environmental issue as well. But can't >> find anything so >> > far. >> > >> > Regards, >> > >> > Peter >> > >> > >> > On Mon, Oct 13, 2014 at 8:29 PM, Toma? Cerar < >> tomaz.cerar at gmail.com >> > > wrote: >> > >> > os? jvm? arch? >> > >> > looking at our nightly jobs whole testsuite passes >> on our CI with >> > JDK7 & 8 on windows and on linux. >> > >> > I am guessing it must be environmental issue. >> > >> > >> > On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai < >> qutpeter at gmail.com > >> > wrote: >> > >> > Hi, >> > >> > It looks like that the current HEAD of Wildfly will >> failed when >> > running smoke testing with the following information: >> > >> > Results : >> > >> > Failed tests: >> > >> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 >> > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, >> > 342ae7aec9bff370e3de8704ed9642a718986e61]> but >> > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> >> > >> > Any cues? >> > >> > Regards, >> > >> > _______________________________________________ >> > 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 >> > >> > >> > >> > -- >> > >> > >> > ________________ __________ >> > >> > >> > Eduardo Sant'Ana da Silva - Dr. >> > Pesquisador / Consultor de TI >> > >> > >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> -- >> __________________________ >> Eduardo Sant'Ana da Silva - Dr. >> Pesquisador / Consultor de TI >> >> >> >> _______________________________________________ >> 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Tue Oct 21 18:28:21 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 21 Oct 2014 17:28:21 -0500 Subject: [wildfly-dev] smoke testing failure In-Reply-To: <5446BFDA.9090601@redhat.com> References: <17398798.5184.1413263981421.JavaMail.joe@localhost.localdomain> <5444D547.2000008@gmail.com> <5446BFDA.9090601@redhat.com> Message-ID: <5446DE05.2080402@redhat.com> On 10/21/14, 3:19 PM, Brian Stansberry wrote: > Thanks, Jaikiran. > > I think this is almost certainly due to these: > > testFilesystemDeployment_Marker() > testFilesystemDeployment_Auto() > > All implement the test's utility class' DeploymentExecutor.undeploy() > method by deleting a file in a deployment scanner directory, and then > don't wait to validate the completion of scanner execution. In each of > those three the testDeployments method can return once the deployment is > out of the runtime and therefore no longer visible via JMX but before > the completion of the management op. The removal from the content > repository is done as part of completion of the management op. (It's not > a background process.) > > This is a problem that went undetected for years because the scanner was > treating zips as non-managed deployments, and not uploading them to the > content repo. That was recently changed. > > I think the fix is to have those DeploymentExecutor.undeploy() methods > block until the .undeployed marker file appears or some reasonable > timeout happens. > https://issues.jboss.org/browse/WFLY-4005 Fix is https://github.com/wildfly/wildfly/pull/6851 > OT: every test in this package needs to be moved to the wildfly-core > testsuite. https://issues.jboss.org/browse/WFCORE-193 if anyone wants to take that on > > On 10/20/14, 4:26 AM, Jaikiran Pai wrote: >> Saw the same issue locally and from what I see in that testcase, it >> doesn't appear to be a JVM vendor/version issue. This actually is a race >> condition in the test method execution and removal of content from >> content repository. >> >> That ServerInModuleDeploymentTestCase testcase has multiple test methods >> which deal with deploying and undeploying. From what I am observing it >> looks like one of the test methods first runs (I guess the >> testDeploymentFileApi) and does its deploy/undeploy sequence and then >> the testDeploymentStreamApi runs which first does a file listing of the >> content directory and turns out the undeploy operation from the previous >> test method hasn't yet removed the content from the content repository >> yet. So this test picks up those (to be deleted) hashes as initial >> hashes in the content repo. While this test method is running, a >> background thread cleans up previously undeployed the hashes from the >> content repository. As a result a subsequent file listing of the content >> directory from this current test method doesn't find those expected >> initial hashes. >> >> I'm not sure what the expected behaviour of a undeploy operation is - >> whether the undeploy should complete only after the content has been >> removed (probably not) from the content repository or whether it can >> return before that (as it seems to be happening now). >> >> FWIW, here's my environment details: >> >> java version "1.7.0_15" >> Java(TM) SE Runtime Environment (build 1.7.0_15-b03) >> Java HotSpot(TM) Server VM (build 23.7-b01, mixed mode) >> >> Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.618 >> sec <<< FAILURE! - in >> org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase >> testDeploymentStreamApi(org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase) >> Time elapsed: 0.473 sec <<< FAILURE! >> java.lang.AssertionError: >> expected:<[29c4c47c1224a00169a8df02d84c3d6ff014b5fb, >> b9227c99efad4b615df0ad5288b6690216ed7bad]> but >> was:<[29c4c47c1224a00169a8df02d84c3d6ff014b5fb]> >> at org.junit.Assert.fail(Assert.java:88) >> at org.junit.Assert.failNotEquals(Assert.java:743) >> at org.junit.Assert.assertEquals(Assert.java:118) >> at org.junit.Assert.assertEquals(Assert.java:144) >> at >> org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeployments(ServerInModuleDeploymentTestCase.java:618) >> at >> org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeploymentStreamApi(ServerInModuleDeploymentTestCase.java:96) >> >> >> -Jaikiran >> On Wednesday 15 October 2014 06:28 PM, Eduardo Sant?Ana da Silva wrote: >>> Could be some change regarding some message digest used on ShrinkWrap >>> API based upon a different JVM version? >>> >>> Just a guess... >>> >>> --- >>> Eduardo Sant'Ana da Silva >>> >>> 2014-10-15 1:40 GMT-03:00 Peter Cai >> >: >>> >>> Well, I have no luck on tracking down what is happening in this >>> test case. >>> But things is becoming more interesting. >>> I can partially repeat the failure on Windows 8. >>> Now, on both Ubuntu 14.04 and Windows 8, using JVM 1.7.0_51, >>> run the test from the smoke testing module. i.e., >>> cd testsuite\integration\smoke >>> mvn clean test >>> -Dtest=org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase >>> Interestingly, this testcase sometimes passes, sometimes fails. >>> When failed, with the following info: >>> Failed tests: >>> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 >>> expected:<[504917ff8990a5f90995d412117e39afbdaf6747]> but was:<[]> >>> Regards, >>> Peter >>> >>> On Tue, Oct 14, 2014 at 10:33 PM, Peter Cai >> > wrote: >>> >>> On my side, I use "mvn -fae -Dmaven.test.failure.ignore=true >>> clean install", this test mentioned above is the only test >>> that failed. >>> >>> I am trying to track it down. >>> >>> Regards, >>> Peter >>> >>> On Tue, Oct 14, 2014 at 7:23 PM, Toma? Cerar >>> > wrote: >>> >>> Guys, is problem only this test or also something else? >>> >>> it is possible that this tests has problems that makes it >>> fail on certain scenarios. >>> >>> Any chance anyone of you that can reproduce it, can try to >>> track it down what the issue is? >>> >>> if you add "-fae -Dmaven.test.failure.ignore=true " as >>> param to build, it will continue building/testing after >>> test failure(s), >>> so you can see what all tests fail for you or only this one. >>> >>> On Tue, Oct 14, 2014 at 7:19 AM, Edward Wertz >>> > wrote: >>> >>> I've gotten that error for a while, so you're not >>> alone, but haven't been able to track it down either, >>> so I'm not much help fixing it. Java/Maven versions >>> don't effect it and I can build fine on my Windows 7 >>> machine. It's a mystery to me what's causing it. >>> >>> Linux localhost.localdomain 3.16.2-201.fc20.x86_64 #1 >>> SMP Mon Sep 15 19:57:50 UTC 2014 x86_64 x86_64 x86_64 >>> GNU/Linux >>> LSB Version: >>> :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch >>> Distributor ID: Fedora >>> Description: Fedora release 20 (Heisenbug) >>> Release: 20 >>> Codename: Heisenbug >>> >>> Joe Wertz >>> >>> >>> ----- Original Message ----- >>> > From: "Eduardo Sant?Ana da Silva" >>> >> > >>> > To: "Peter Cai" >> > >>> > Cc: wildfly-dev at lists.jboss.org >>> >>> > Sent: Tuesday, October 14, 2014 8:29:11 AM >>> > Subject: Re: [wildfly-dev] smoke testing failure >>> > >>> > >>> > >>> > I've made the build successfully on the following >>> environment as >>> > well: >>> > >>> > OS X 10.9.5 >>> > java version "1.8.0_05" >>> > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>> > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, >>> mixed mode) >>> > >>> > >>> > 2014-10-13 20:19 GMT-03:00 Peter Cai < >>> qutpeter at gmail.com > : >>> > >>> > It should be some environmental issue. >>> > I can successfully run the smoke test on Windows 8, >>> > >>> > And the JVM is: >>> > java version "1.7.0_51" >>> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >>> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, >>> mixed mode) >>> > >>> > Regards >>> > >>> > >>> > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai < >>> qutpeter at gmail.com > >>> > wrote: >>> > >>> > >>> > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP >>> Thu May 15 18:06:16 >>> > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu >>> 14.04 desktop) >>> > >>> > JVM: >>> > java version "1.7.0_51" >>> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) >>> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, >>> mixed mode) >>> > >>> > My guess is environmental issue as well. But can't >>> find anything so >>> > far. >>> > >>> > Regards, >>> > >>> > Peter >>> > >>> > >>> > On Mon, Oct 13, 2014 at 8:29 PM, Toma? Cerar < >>> tomaz.cerar at gmail.com >>> > > wrote: >>> > >>> > os? jvm? arch? >>> > >>> > looking at our nightly jobs whole testsuite passes >>> on our CI with >>> > JDK7 & 8 on windows and on linux. >>> > >>> > I am guessing it must be environmental issue. >>> > >>> > >>> > On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai < >>> qutpeter at gmail.com > >>> > wrote: >>> > >>> > Hi, >>> > >>> > It looks like that the current HEAD of Wildfly will >>> failed when >>> > running smoke testing with the following information: >>> > >>> > Results : >>> > >>> > Failed tests: >>> > >>> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614 >>> > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5, >>> > 342ae7aec9bff370e3de8704ed9642a718986e61]> but >>> > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]> >>> > >>> > Any cues? >>> > >>> > Regards, >>> > >>> > _______________________________________________ >>> > 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 >>> > >>> > >>> > >>> > -- >>> > >>> > >>> > ________________ __________ >>> > >>> > >>> > Eduardo Sant'Ana da Silva - Dr. >>> > Pesquisador / Consultor de TI >>> > >>> > >>> > >>> > _______________________________________________ >>> > wildfly-dev mailing list >>> > wildfly-dev at lists.jboss.org >>> >>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >>> >>> -- >>> __________________________ >>> Eduardo Sant'Ana da Silva - Dr. >>> Pesquisador / Consultor de TI >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From stuart.w.douglas at gmail.com Wed Oct 22 00:08:59 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 22 Oct 2014 15:08:59 +1100 Subject: [wildfly-dev] Behavior of javax.servlet.ServletResponse#isCommitted In-Reply-To: <395451817.8592599.1413903212013.JavaMail.zimbra@redhat.com> References: <305394183.8574951.1413901773805.JavaMail.zimbra@redhat.com> <395451817.8592599.1413903212013.JavaMail.zimbra@redhat.com> Message-ID: It should be fixed in the latest Undertow build, which should make it into Wildfly upstream shortly. On Wed, Oct 22, 2014 at 1:53 AM, Pedro Igor Silva wrote: > Hi, > > I'm using latest build from wildfly upstream/master. > > Would like to know if there is an issue on how Undertow recognize that > a response is already commited or not. > > My code is setting a header and sending an error like that > > response.setHeader(REQUIRES_AUTHENTICATION_HEADER_NAME, > AUTHENTICATION_SCHEME_NAME); > response.sendError(HttpServletResponse.SC_UNAUTHORIZED); > > and isCommited is always returning "false" after that. To change this > behavior I have to force a flush, so isCommited returns true. > > Both WildFly 8.1.0.Final and EAP behave differently and isCommited > returns "true" without requiring a manual flush. Is this an issue ? > > Regards. > Pedro Igor > _______________________________________________ > 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/20141022/89e4c370/attachment.html From darran.lofthouse at jboss.com Wed Oct 22 11:42:31 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 22 Oct 2014 16:42:31 +0100 Subject: [wildfly-dev] WildFly Elytron Discussions Message-ID: <5447D067.9000406@jboss.com> As we are a small team of engineers distributed across multiple timezones we have decided to move our discssions from IRC to HipChat, to chat about Elytron use the wildfly-elytron room. If you do not have access to HipChat guest access is available here http://www.hipchat.com/gKoTFkUyg Regards, Darran Lofthouse. From luis.m.costa at gmail.com Wed Oct 22 19:18:28 2014 From: luis.m.costa at gmail.com (=?UTF-8?B?THXDrXMgTS4gQ29zdGE=?=) Date: Thu, 23 Oct 2014 00:18:28 +0100 Subject: [wildfly-dev] Include new EJB Client in Wildfly 8.2 In-Reply-To: References: Message-ID: Hi! I would like to suggest to include the new EJB Client version in next wildfly 8.2 release. My request is a little more detail in this forum entry: https://developer.jboss.org/message/907747 Thanks for your help, Lu?s M. Costa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141023/b6c78092/attachment.html From tdiesler at redhat.com Thu Oct 23 02:46:21 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Thu, 23 Oct 2014 08:46:21 +0200 Subject: [wildfly-dev] Where can I find the EAP version of jboss-as Message-ID: <9172F31B-22A4-485F-8353-D17FE8363BCC@redhat.com> Folks, apparently EAP-6.4 is going to be based on jboss-as-7.4.0.Final. Is that correct? Where can I find the sources + maven artefacts. cheers ?thomas From bbaranow at redhat.com Thu Oct 23 03:01:41 2014 From: bbaranow at redhat.com (Bartosz Baranowski) Date: Thu, 23 Oct 2014 03:01:41 -0400 (EDT) Subject: [wildfly-dev] Where can I find the EAP version of jboss-as In-Reply-To: <9172F31B-22A4-485F-8353-D17FE8363BCC@redhat.com> References: <9172F31B-22A4-485F-8353-D17FE8363BCC@redhat.com> Message-ID: <632795616.50153914.1414047701191.JavaMail.zimbra@redhat.com> Content moderated (rt321697) ----- Original Message ----- > From: "Thomas Diesler" > To: "WildFly Dev" > Sent: Thursday, October 23, 2014 8:46:21 AM > Subject: [wildfly-dev] Where can I find the EAP version of jboss-as > > Folks, > > apparently EAP-6.4 is going to be based on jboss-as-7.4.0.Final. Is that > correct? > > Where can I find the sources + maven artefacts. > > cheers > ?thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Thu Oct 23 05:09:58 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 23 Oct 2014 10:09:58 +0100 Subject: [wildfly-dev] Where can I find the EAP version of jboss-as In-Reply-To: <632795616.50153914.1414047701191.JavaMail.zimbra@redhat.com> References: <9172F31B-22A4-485F-8353-D17FE8363BCC@redhat.com> <632795616.50153914.1414047701191.JavaMail.zimbra@redhat.com> Message-ID: Content moderated (rt321697) > On 23 Oct 2014, at 08:01, Bartosz Baranowski wrote: > > > ----- Original Message ----- >> From: "Thomas Diesler" >> To: "WildFly Dev" >> Sent: Thursday, October 23, 2014 8:46:21 AM >> Subject: [wildfly-dev] Where can I find the EAP version of jboss-as >> >> Folks, >> >> apparently EAP-6.4 is going to be based on jboss-as-7.4.0.Final. Is that >> correct? >> >> Where can I find the sources + maven artefacts. >> >> cheers >> ?thomas >> _______________________________________________ >> 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 tdiesler at redhat.com Thu Oct 23 05:11:40 2014 From: tdiesler at redhat.com (Thomas Diesler) Date: Thu, 23 Oct 2014 11:11:40 +0200 Subject: [wildfly-dev] Where can I find the EAP version of jboss-as In-Reply-To: References: <9172F31B-22A4-485F-8353-D17FE8363BCC@redhat.com> <632795616.50153914.1414047701191.JavaMail.zimbra@redhat.com> Message-ID: Great - Thanks > On 23 Oct 2014, at 11:09, Kabir Khan wrote: > > >> On 23 Oct 2014, at 08:01, Bartosz Baranowski wrote: >> >> >> ----- Original Message ----- >>> From: "Thomas Diesler" >>> To: "WildFly Dev" >>> Sent: Thursday, October 23, 2014 8:46:21 AM >>> Subject: [wildfly-dev] Where can I find the EAP version of jboss-as >>> >>> Folks, >>> >>> apparently EAP-6.4 is going to be based on jboss-as-7.4.0.Final. Is that >>> correct? >>> >>> Where can I find the sources + maven artefacts. >>> >>> cheers >>> ?thomas >>> _______________________________________________ >>> 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 david.lloyd at redhat.com Fri Oct 24 15:24:53 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 24 Oct 2014 14:24:53 -0500 Subject: [wildfly-dev] About last week's core release... In-Reply-To: <544504A7.5050802@redhat.com> References: <544504A7.5050802@redhat.com> Message-ID: <544AA785.4070600@redhat.com> On 10/20/2014 07:48 AM, David M. Lloyd wrote: > Last Friday I prepared the wildfly-core 1.0.0.Alpha10 release. It's in > a staging repo up on Nexus right now - however, Brontes was down (as was > the entire Brno data center, due to maintenance, I hear) so I was unable > to do a clean test of WildFly with the updated core, thus the release > hasn't happened. > > We'll shoot for early this week. If however the testing fails, then > there will likely be no "last week" release, and instead we'll try again > this Friday. This week the build failed partway through resulting in 328 failed tests. Unless Stuart can sort it out, it looks like this week's release is a no-go as well. -- - DML From claudio at claudius.com.br Sat Oct 25 08:33:06 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Sat, 25 Oct 2014 10:33:06 -0200 Subject: [wildfly-dev] WFLY-3512 - disable datasource undeploy application Message-ID: Hi, related to WFLY-3512, disable a datasource used by some application, undeploy the application, tested in 8.1 and 9.0 snapshot. I saw that org.jboss.as.connector.subsystems.datasources.DataSourceDisable (connector module) is called, but there is no previous check about deployments that uses it. How can datasource subsystem get to know the deployment dependencies for resources (datasource and resource adapter) ? Is there a listener mechanism where datasource subsystem can listen to deploy enablement, and check the resources dependencies ? This way, datasource subsystem can have a lista of dependency and check it before disable/remove of datasources. 1. https://issues.jboss.org/browse/WFLY-3512 -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From brian.stansberry at redhat.com Mon Oct 27 11:27:55 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 27 Oct 2014 10:27:55 -0500 Subject: [wildfly-dev] WFLY-3512 - disable datasource undeploy application In-Reply-To: References: Message-ID: <544E647B.9020803@redhat.com> The datasource subsystem shouldn't need to know that kind of information. When the operation rolls back it should restore the services it removed, and MSC will take care of bringing back up whatever services were stopped when the DS services were removed. This needs fixing: https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/subsystems/datasources/AbstractDataSourceRemove.java#L111 On 10/25/14, 7:33 AM, Claudio Miranda wrote: > Hi, related to WFLY-3512, disable a datasource used by some > application, undeploy the application, tested in 8.1 and 9.0 snapshot. > > I saw that org.jboss.as.connector.subsystems.datasources.DataSourceDisable > (connector module) is called, but there is no previous check about > deployments that uses it. > How can datasource subsystem get to know the deployment dependencies > for resources (datasource and resource adapter) ? > Is there a listener mechanism where datasource subsystem can listen to > deploy enablement, and check the resources dependencies ? This way, > datasource subsystem can have a lista of dependency and check it > before disable/remove of datasources. > > 1. https://issues.jboss.org/browse/WFLY-3512 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From pat at patgarner.com Mon Oct 27 12:01:53 2014 From: pat at patgarner.com (Patrick Garner) Date: Mon, 27 Oct 2014 12:01:53 -0400 Subject: [wildfly-dev] Difficulty with ImportHandler#importClass() Message-ID: It looks like there is a class loader issue with ImportHandler#importClass(). It's unable to load classes in WEB-INF/classes. After seeking help in JBoss Community, Jaikiran Pai suggested I contact the webdev list. Here is the link to the discussion: https://developer.jboss.org/thread/249727 Any thoughts/ insights you may provide would be so helpful. Regards, Pat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141027/9ad1b7ed/attachment.html From kabir.khan at jboss.com Wed Oct 29 08:16:27 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 29 Oct 2014 12:16:27 +0000 Subject: [wildfly-dev] Core build and testsuite folders Message-ID: <7D7B51AE-6344-49F9-8A4B-C854A95D58B3@jboss.com> Is there any good reason why what are basically the build and testsuite folders are called core-build and testsuite-core in WildFly Core? It is especially annoying to have to remember that it is called core-build, when trying to do tab completion to start a server. From tomaz.cerar at gmail.com Wed Oct 29 08:23:06 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 29 Oct 2014 13:23:06 +0100 Subject: [wildfly-dev] Core build and testsuite folders In-Reply-To: <7D7B51AE-6344-49F9-8A4B-C854A95D58B3@jboss.com> References: <7D7B51AE-6344-49F9-8A4B-C854A95D58B3@jboss.com> Message-ID: No good reason, beyond that it was needed when we ware doing initial code split. I am working on PR that renames testsuite-core back to testsuite and moves few more tests to core. On Wed, Oct 29, 2014 at 1:16 PM, Kabir Khan wrote: > Is there any good reason why what are basically the build and testsuite > folders are called core-build and testsuite-core in WildFly Core? > > It is especially annoying to have to remember that it is called > core-build, when trying to do tab completion to start a server. > > > > _______________________________________________ > 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/20141029/ff777eb0/attachment.html From arun.gupta at gmail.com Wed Oct 29 14:54:27 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Wed, 29 Oct 2014 11:54:27 -0700 Subject: [wildfly-dev] Issues in wildfly-javaee7-webapp-blank-archetype Message-ID: Generated an app as ... mvn archetype:generate -DgroupId=test -DartifactId=test -DarchetypeGroupId=org.wildfly.archetype -DarchetypeArtifactId=wildfly-javaee7-webapp-blank-archetype -DarchetypeVersion=8.1.0.Final The app has the following files: ./src/main/webapp/WEB-INF/beans.xml ./src/main/webapp/WEB-INF/faces-config.xml ./src/main/webapp/WEB-INF/test-ds.xml - beans.xml and faces-config.xml are using java.sun.com-style namespaces instead of xmlns.jcp.org-style namespaces. Filed as https://issues.jboss.org/browse/WFLY-4030 - What is the purpose of test-ds.xml ? It contains: jdbc:h2:mem:test;DB_CLOSE_ON_EXIT=FALSE;DB_CLOSE_DELAY=-1 h2 sa sa This is anyway the default Java EE 7 data source in WildFly. - src/main/META-INF/persistence.xml refers to this datasource. That can be removed as well because of the default Java EE 7 data source. Seems like these are left overs from previous time ? Can this be cleaned up ? Xavier and I are planning to use this archetype for our talk at Devoxx in the next few days and would like a cleaner generated app. Arun -- http://blog.arungupta.me http://twitter.com/arungupta From slaskawi at redhat.com Thu Oct 30 04:28:03 2014 From: slaskawi at redhat.com (=?UTF-8?B?U2ViYXN0aWFuIMWBYXNrYXdpZWM=?=) Date: Thu, 30 Oct 2014 09:28:03 +0100 Subject: [wildfly-dev] Issues in wildfly-javaee7-webapp-blank-archetype In-Reply-To: References: Message-ID: <5451F693.2070807@redhat.com> Hey I would like to volunteer for WFLY-4030 and a Quickstarts change: WFLY-4031. However I'm not sure about removing test-ds.xml. Maybe the point is to show how to add DataSources bundled with the application? On the other hand if this is not the point - I think we should change it to ExampleDS. What's your opinion on that? Best regards Sebastian On 10/29/2014 07:54 PM, Arun Gupta wrote: > - What is the purpose of test-ds.xml ? It contains: > This is anyway the default Java EE 7 data source in WildFly. From jmesnil at redhat.com Thu Oct 30 06:40:07 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 30 Oct 2014 11:40:07 +0100 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> Message-ID: <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). To represent this in the management model, I have added several resources under hornetq-server: /subsystem=messaging/ hornetq-server=*/ ha-policy=live-only ha-policy=replicated-master ha-policy=replicated-slave ha-policy=replicated-colocated ha-policy=shared-store-master ha-policy=shared-store-slave ha-policy=shared-store-colocated I have constraints for this ha-policy resource: * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. Heiko, is it something that would make sense for the console based on this resource description: [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) { "outcome" => "success", "result" => [ { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "replication-colocated") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "replication-master") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "shared-store-slave") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "live-only") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "shared-store-master") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "replication-slave") ], "outcome" => "success", "result" => { ... } }, { "address" => [ ("subsystem" => "messaging"), ("hornetq-server" => "default"), ("ha-policy" => "shared-store-colocated") ], "outcome" => "success", "result" => { ... } } ] } jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From hbraun at redhat.com Thu Oct 30 07:55:36 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 30 Oct 2014 12:55:36 +0100 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> Message-ID: <5870CA2B-A65B-451C-AA3A-8F3B02781FFD@redhat.com> Thanks for the update Jeff. Yes, it's true that singleton resources impose problem when attempting to further automate (read data binding) the UI components we have in the console. But currently I don't believe we can do without them, as they provide a valid and reasonable way to model certain resources. So, with regard to your proposal, I think the way you approach the new hornetq resources is fine. The specific problems we are facing with the UI need to be tackled in general way and breaks down into these questions: - how do we (programmatically) identify singleton resources? - how do we access their resource meta data (:read-resource-desciption)? The fundamental problem (as described in my previous email) is that you cannot tell which resources are singletons when walking the tree using any of the child related operations (read-child-types(), read-children-names()). Currently the only way to go about that is to read child resource recursively and compare their structures. For regular, non-singleton resources the address token key (/=/...) denotes the type. We would need an equivalent way to identify the types for singleton resources as well. This for instance would work for us: /subsystem=messaging/hornetq-sever=*:read-children-types() { "outcome" => "success", "result" => [ ..., "ha-policy=live-only", "ha-policy=replicated-master", "ha-policy=replicated-slave", ... ] } On 30 Oct 2014, at 11:40, Jeff Mesnil wrote: > I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. > > In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). > > To represent this in the management model, I have added several resources under hornetq-server: > > /subsystem=messaging/ > hornetq-server=*/ > ha-policy=live-only > ha-policy=replicated-master > ha-policy=replicated-slave > ha-policy=replicated-colocated > ha-policy=shared-store-master > ha-policy=shared-store-slave > ha-policy=shared-store-colocated > > I have constraints for this ha-policy resource: > * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. > * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) > > Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. > > I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. > > I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. > > Heiko, is it something that would make sense for the console based on this resource description: > > [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) > { > "outcome" => "success", > "result" => [ > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "replication-colocated") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "replication-master") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "shared-store-slave") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "live-only") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "shared-store-master") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "replication-slave") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "shared-store-colocated") > ], > "outcome" => "success", > "result" => { > ... > } > } > ] > } > > jeff > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > From arun.gupta at gmail.com Thu Oct 30 08:04:43 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 30 Oct 2014 05:04:43 -0700 Subject: [wildfly-dev] Issues in wildfly-javaee7-webapp-blank-archetype In-Reply-To: <5451F693.2070807@redhat.com> References: <5451F693.2070807@redhat.com> Message-ID: For Java EE 7, a default data source is available if none is specified in persistence.xml. In WildFly, this is mapped to ExampleDS already. Does test-ds.xml create a new data source, or map to an existing one ? Arun On Thu, Oct 30, 2014 at 1:28 AM, Sebastian ?askawiec wrote: > Hey > > I would like to volunteer for WFLY-4030 and a Quickstarts change: WFLY-4031. > > However I'm not sure about removing test-ds.xml. Maybe the point is to > show how to add DataSources bundled with the application? > On the other hand if this is not the point - I think we should change it > to ExampleDS. > > What's your opinion on that? > > Best regards > Sebastian > > On 10/29/2014 07:54 PM, Arun Gupta wrote: >> - What is the purpose of test-ds.xml ? It contains: >> This is anyway the default Java EE 7 data source in WildFly. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- http://blog.arungupta.me http://twitter.com/arungupta From david.lloyd at redhat.com Thu Oct 30 09:01:09 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 30 Oct 2014 08:01:09 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> Message-ID: <54523695.2090409@redhat.com> I think that polymorphism is a new use case for 'squatters'. I wonder if we have any existing code which enforces single children? On 10/30/2014 05:40 AM, Jeff Mesnil wrote: > I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. > > In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). > > To represent this in the management model, I have added several resources under hornetq-server: > > /subsystem=messaging/ > hornetq-server=*/ > ha-policy=live-only > ha-policy=replicated-master > ha-policy=replicated-slave > ha-policy=replicated-colocated > ha-policy=shared-store-master > ha-policy=shared-store-slave > ha-policy=shared-store-colocated > > I have constraints for this ha-policy resource: > * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. > * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) > > Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. > > I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. > > I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. > > Heiko, is it something that would make sense for the console based on this resource description: > > [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) > { > "outcome" => "success", > "result" => [ > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "replication-colocated") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "replication-master") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "shared-store-slave") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "live-only") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "shared-store-master") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "replication-slave") > ], > "outcome" => "success", > "result" => { > ... > } > }, > { > "address" => [ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("ha-policy" => "shared-store-colocated") > ], > "outcome" => "success", > "result" => { > ... > } > } > ] > } > > jeff > -- - DML From david.lloyd at redhat.com Thu Oct 30 09:08:34 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 30 Oct 2014 08:08:34 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <54523695.2090409@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> Message-ID: <54523852.1070908@redhat.com> I mean, a single child where there can be many possible types for that child. On 10/30/2014 08:01 AM, David M. Lloyd wrote: > I think that polymorphism is a new use case for 'squatters'. I wonder > if we have any existing code which enforces single children? > > On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >> >> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >> >> To represent this in the management model, I have added several resources under hornetq-server: >> >> /subsystem=messaging/ >> hornetq-server=*/ >> ha-policy=live-only >> ha-policy=replicated-master >> ha-policy=replicated-slave >> ha-policy=replicated-colocated >> ha-policy=shared-store-master >> ha-policy=shared-store-slave >> ha-policy=shared-store-colocated >> >> I have constraints for this ha-policy resource: >> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >> >> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >> >> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >> >> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >> >> Heiko, is it something that would make sense for the console based on this resource description: >> >> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >> { >> "outcome" => "success", >> "result" => [ >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-colocated") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-master") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-slave") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "live-only") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-master") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-slave") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-colocated") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> } >> ] >> } >> >> jeff >> > -- - DML From jmesnil at redhat.com Thu Oct 30 09:18:47 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 30 Oct 2014 14:18:47 +0100 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <54523852.1070908@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <54523852.1070908@redhat.com> Message-ID: > On 30 Oct 2014, at 14:08, David M. Lloyd wrote: > > I mean, a single child where there can be many possible types for that > child. I did no find any other such cases. BTW, I?m not bent on that representation. If there is a better way to represent such a ha-policy resource, I?m open to change its model. Having a single child looks to be the best way to have a self-contained representation of the HA feature of HornetQ (instead of cluttering the hornet-server itself with many conflicting attributes) but I prefer to be consistent with other models in WFLY if we already have some. -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From brian.stansberry at redhat.com Thu Oct 30 09:44:11 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 30 Oct 2014 08:44:11 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <54523852.1070908@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <54523852.1070908@redhat.com> Message-ID: <545240AB.3060705@redhat.com> No, we don't. That currently would have to be handled in a custom way by the OSH that does the add for any of the children. There are some bits and pieces in the metadata that can help with doing some sort of automated validation (i.e. a currently basically unused max/min child count thing) but I don't think what's there is sufficient. The fact the metadata isn't there means a client like the console couldn't enforce the constraint server side, for a better UX. On 10/30/14, 8:08 AM, David M. Lloyd wrote: > I mean, a single child where there can be many possible types for that > child. > > On 10/30/2014 08:01 AM, David M. Lloyd wrote: >> I think that polymorphism is a new use case for 'squatters'. I wonder >> if we have any existing code which enforces single children? >> >> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>> >>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>> >>> To represent this in the management model, I have added several resources under hornetq-server: >>> >>> /subsystem=messaging/ >>> hornetq-server=*/ >>> ha-policy=live-only >>> ha-policy=replicated-master >>> ha-policy=replicated-slave >>> ha-policy=replicated-colocated >>> ha-policy=shared-store-master >>> ha-policy=shared-store-slave >>> ha-policy=shared-store-colocated >>> >>> I have constraints for this ha-policy resource: >>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>> >>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>> >>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>> >>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>> >>> Heiko, is it something that would make sense for the console based on this resource description: >>> >>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>> { >>> "outcome" => "success", >>> "result" => [ >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "live-only") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> } >>> ] >>> } >>> >>> jeff >>> >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Thu Oct 30 09:56:03 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 30 Oct 2014 08:56:03 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <545240AB.3060705@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <54523852.1070908@redhat.com> <545240AB.3060705@redhat.com> Message-ID: <54524373.20402@redhat.com> On 10/30/14, 8:44 AM, Brian Stansberry wrote: > No, we don't. That currently would have to be handled in a custom way by > the OSH that does the add for any of the children. > > There are some bits and pieces in the metadata that can help with doing > some sort of automated validation (i.e. a currently basically unused > max/min child count thing) but I don't think what's there is sufficient. > > The fact the metadata isn't there means a client like the console > couldn't enforce the constraint server side, for a better UX. > I mean "client side" not "server side". > On 10/30/14, 8:08 AM, David M. Lloyd wrote: >> I mean, a single child where there can be many possible types for that >> child. >> >> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>> I think that polymorphism is a new use case for 'squatters'. I wonder >>> if we have any existing code which enforces single children? >>> >>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>> >>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>> >>>> To represent this in the management model, I have added several resources under hornetq-server: >>>> >>>> /subsystem=messaging/ >>>> hornetq-server=*/ >>>> ha-policy=live-only >>>> ha-policy=replicated-master >>>> ha-policy=replicated-slave >>>> ha-policy=replicated-colocated >>>> ha-policy=shared-store-master >>>> ha-policy=shared-store-slave >>>> ha-policy=shared-store-colocated >>>> >>>> I have constraints for this ha-policy resource: >>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>> >>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>> >>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>> >>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>> >>>> Heiko, is it something that would make sense for the console based on this resource description: >>>> >>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>> { >>>> "outcome" => "success", >>>> "result" => [ >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "live-only") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> } >>>> ] >>>> } >>>> >>>> jeff >>>> >>> >> > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Thu Oct 30 09:58:27 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 30 Oct 2014 08:58:27 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <545240AB.3060705@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <54523852.1070908@redhat.com> <545240AB.3060705@redhat.com> Message-ID: <54524403.1080805@redhat.com> Using schema-ish things like min/max was probably a bad idea on my part. After trying to model XML schema in various ways for various reasons over the years, I know now that the simpler our rules are, the easier it will be to implement a cohesive and useful UX. IMO any currently unused and un-useful constructs like this that are hanging around probably need to be pruned, before someone actually uses them and makes everyone's live more difficult. :-) On 10/30/2014 08:44 AM, Brian Stansberry wrote: > No, we don't. That currently would have to be handled in a custom way by > the OSH that does the add for any of the children. > > There are some bits and pieces in the metadata that can help with doing > some sort of automated validation (i.e. a currently basically unused > max/min child count thing) but I don't think what's there is sufficient. > > The fact the metadata isn't there means a client like the console > couldn't enforce the constraint server side, for a better UX. > > On 10/30/14, 8:08 AM, David M. Lloyd wrote: >> I mean, a single child where there can be many possible types for that >> child. >> >> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>> I think that polymorphism is a new use case for 'squatters'. I wonder >>> if we have any existing code which enforces single children? >>> >>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>> >>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>> >>>> To represent this in the management model, I have added several resources under hornetq-server: >>>> >>>> /subsystem=messaging/ >>>> hornetq-server=*/ >>>> ha-policy=live-only >>>> ha-policy=replicated-master >>>> ha-policy=replicated-slave >>>> ha-policy=replicated-colocated >>>> ha-policy=shared-store-master >>>> ha-policy=shared-store-slave >>>> ha-policy=shared-store-colocated >>>> >>>> I have constraints for this ha-policy resource: >>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>> >>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>> >>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>> >>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>> >>>> Heiko, is it something that would make sense for the console based on this resource description: >>>> >>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>> { >>>> "outcome" => "success", >>>> "result" => [ >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "live-only") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> } >>>> ] >>>> } >>>> >>>> jeff >>>> >>> >> > > -- - DML From brian.stansberry at redhat.com Thu Oct 30 10:00:08 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 30 Oct 2014 09:00:08 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <54524403.1080805@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <54523852.1070908@redhat.com> <545240AB.3060705@redhat.com> <54524403.1080805@redhat.com> Message-ID: <54524468.2080404@redhat.com> I'm not so sure that bad idea was yours. But +1 on getting rid of the existing min/max thing. On 10/30/14, 8:58 AM, David M. Lloyd wrote: > Using schema-ish things like min/max was probably a bad idea on my part. > After trying to model XML schema in various ways for various reasons > over the years, I know now that the simpler our rules are, the easier it > will be to implement a cohesive and useful UX. > > IMO any currently unused and un-useful constructs like this that are > hanging around probably need to be pruned, before someone actually uses > them and makes everyone's live more difficult. :-) > > On 10/30/2014 08:44 AM, Brian Stansberry wrote: >> No, we don't. That currently would have to be handled in a custom way by >> the OSH that does the add for any of the children. >> >> There are some bits and pieces in the metadata that can help with doing >> some sort of automated validation (i.e. a currently basically unused >> max/min child count thing) but I don't think what's there is sufficient. >> >> The fact the metadata isn't there means a client like the console >> couldn't enforce the constraint server side, for a better UX. >> >> On 10/30/14, 8:08 AM, David M. Lloyd wrote: >>> I mean, a single child where there can be many possible types for that >>> child. >>> >>> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>>> I think that polymorphism is a new use case for 'squatters'. I wonder >>>> if we have any existing code which enforces single children? >>>> >>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>> >>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>> >>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>> >>>>> /subsystem=messaging/ >>>>> hornetq-server=*/ >>>>> ha-policy=live-only >>>>> ha-policy=replicated-master >>>>> ha-policy=replicated-slave >>>>> ha-policy=replicated-colocated >>>>> ha-policy=shared-store-master >>>>> ha-policy=shared-store-slave >>>>> ha-policy=shared-store-colocated >>>>> >>>>> I have constraints for this ha-policy resource: >>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>> >>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>> >>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>> >>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>> >>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>> >>>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>> { >>>>> "outcome" => "success", >>>>> "result" => [ >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-colocated") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-master") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-slave") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "live-only") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-master") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-slave") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-colocated") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> } >>>>> ] >>>>> } >>>>> >>>>> jeff >>>>> >>>> >>> >> >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Thu Oct 30 10:06:27 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 30 Oct 2014 09:06:27 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <54523695.2090409@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> Message-ID: Is it really polymorphism though if you do not share attributes or operations? It sounds like these are all distinct types just sharing the same portion of an address. The primary justification for this modeling approach seems to be: 1) Avoid the user having to assign a name 2) Enforce a single occurrence of a ?type? > On Oct 30, 2014, at 8:01 AM, David M. Lloyd wrote: > > I think that polymorphism is a new use case for 'squatters'. I wonder > if we have any existing code which enforces single children? > > On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >> >> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >> >> To represent this in the management model, I have added several resources under hornetq-server: >> >> /subsystem=messaging/ >> hornetq-server=*/ >> ha-policy=live-only >> ha-policy=replicated-master >> ha-policy=replicated-slave >> ha-policy=replicated-colocated >> ha-policy=shared-store-master >> ha-policy=shared-store-slave >> ha-policy=shared-store-colocated >> >> I have constraints for this ha-policy resource: >> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >> >> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >> >> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >> >> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >> >> Heiko, is it something that would make sense for the console based on this resource description: >> >> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >> { >> "outcome" => "success", >> "result" => [ >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-colocated") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-master") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-slave") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "live-only") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-master") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-slave") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-colocated") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> } >> ] >> } >> >> jeff >> > > -- > - DML > _______________________________________________ > 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 jason.greene at redhat.com Thu Oct 30 10:12:18 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 30 Oct 2014 09:12:18 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <54524468.2080404@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <54523852.1070908@redhat.com> <545240AB.3060705@redhat.com> <54524403.1080805@redhat.com> <54524468.2080404@redhat.com> Message-ID: <6BB822B2-F68D-4197-A9BE-19ED9007FB4B@redhat.com> It sounds like in this case min/max is unnecessary because of the 1:1 address to name relationship. I think Jeff?s case is easily solved by returning fully qualified address based resource definitions. For example, if you do: /subsystem=messaging=*:read-resource-definition If the result contained nested N sets of resource definitions, as previously discussed, it?s all pretty straight forward. > On Oct 30, 2014, at 9:00 AM, Brian Stansberry wrote: > > I'm not so sure that bad idea was yours. > > But +1 on getting rid of the existing min/max thing. > > On 10/30/14, 8:58 AM, David M. Lloyd wrote: >> Using schema-ish things like min/max was probably a bad idea on my part. >> After trying to model XML schema in various ways for various reasons >> over the years, I know now that the simpler our rules are, the easier it >> will be to implement a cohesive and useful UX. >> >> IMO any currently unused and un-useful constructs like this that are >> hanging around probably need to be pruned, before someone actually uses >> them and makes everyone's live more difficult. :-) >> >> On 10/30/2014 08:44 AM, Brian Stansberry wrote: >>> No, we don't. That currently would have to be handled in a custom way by >>> the OSH that does the add for any of the children. >>> >>> There are some bits and pieces in the metadata that can help with doing >>> some sort of automated validation (i.e. a currently basically unused >>> max/min child count thing) but I don't think what's there is sufficient. >>> >>> The fact the metadata isn't there means a client like the console >>> couldn't enforce the constraint server side, for a better UX. >>> >>> On 10/30/14, 8:08 AM, David M. Lloyd wrote: >>>> I mean, a single child where there can be many possible types for that >>>> child. >>>> >>>> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>>>> I think that polymorphism is a new use case for 'squatters'. I wonder >>>>> if we have any existing code which enforces single children? >>>>> >>>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>>> >>>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>>> >>>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>>> >>>>>> /subsystem=messaging/ >>>>>> hornetq-server=*/ >>>>>> ha-policy=live-only >>>>>> ha-policy=replicated-master >>>>>> ha-policy=replicated-slave >>>>>> ha-policy=replicated-colocated >>>>>> ha-policy=shared-store-master >>>>>> ha-policy=shared-store-slave >>>>>> ha-policy=shared-store-colocated >>>>>> >>>>>> I have constraints for this ha-policy resource: >>>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>>> >>>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>>> >>>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>>> >>>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>>> >>>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>>> >>>>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>>> { >>>>>> "outcome" => "success", >>>>>> "result" => [ >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "replication-colocated") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "replication-master") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "shared-store-slave") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "live-only") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "shared-store-master") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "replication-slave") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> }, >>>>>> { >>>>>> "address" => [ >>>>>> ("subsystem" => "messaging"), >>>>>> ("hornetq-server" => "default"), >>>>>> ("ha-policy" => "shared-store-colocated") >>>>>> ], >>>>>> "outcome" => "success", >>>>>> "result" => { >>>>>> ... >>>>>> } >>>>>> } >>>>>> ] >>>>>> } >>>>>> >>>>>> jeff >>>>>> >>>>> >>>> >>> >>> >> > > > -- > 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 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Thu Oct 30 10:15:28 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 30 Oct 2014 09:15:28 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <6BB822B2-F68D-4197-A9BE-19ED9007FB4B@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <54523852.1070908@redhat.com> <545240AB.3060705@redhat.com> <54524403.1080805@redhat.com> <54524468.2080404@redhat.com> <6BB822B2-F68D-4197-A9BE-19ED9007FB4B@redhat.com> Message-ID: <3EE5F2EC-FDA4-4524-8F5F-3FE43182968A@redhat.com> Wow I am error-prone in the morning! "1:1 address to name relationship? -> 1:1 address to description relationship "/subsystem=messaging=*:read-resource-definition? -> subsystem=messaging=*:read-resource-description > On Oct 30, 2014, at 9:12 AM, Jason Greene wrote: > > It sounds like in this case min/max is unnecessary because of the 1:1 address to name relationship. I think Jeff?s case is easily solved by returning fully qualified address based resource definitions. For example, if you do: > > /subsystem=messaging=*:read-resource-definition > > If the result contained nested N sets of resource definitions, as previously discussed, it?s all pretty straight forward. > > >> On Oct 30, 2014, at 9:00 AM, Brian Stansberry wrote: >> >> I'm not so sure that bad idea was yours. >> >> But +1 on getting rid of the existing min/max thing. >> >> On 10/30/14, 8:58 AM, David M. Lloyd wrote: >>> Using schema-ish things like min/max was probably a bad idea on my part. >>> After trying to model XML schema in various ways for various reasons >>> over the years, I know now that the simpler our rules are, the easier it >>> will be to implement a cohesive and useful UX. >>> >>> IMO any currently unused and un-useful constructs like this that are >>> hanging around probably need to be pruned, before someone actually uses >>> them and makes everyone's live more difficult. :-) >>> >>> On 10/30/2014 08:44 AM, Brian Stansberry wrote: >>>> No, we don't. That currently would have to be handled in a custom way by >>>> the OSH that does the add for any of the children. >>>> >>>> There are some bits and pieces in the metadata that can help with doing >>>> some sort of automated validation (i.e. a currently basically unused >>>> max/min child count thing) but I don't think what's there is sufficient. >>>> >>>> The fact the metadata isn't there means a client like the console >>>> couldn't enforce the constraint server side, for a better UX. >>>> >>>> On 10/30/14, 8:08 AM, David M. Lloyd wrote: >>>>> I mean, a single child where there can be many possible types for that >>>>> child. >>>>> >>>>> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>>>>> I think that polymorphism is a new use case for 'squatters'. I wonder >>>>>> if we have any existing code which enforces single children? >>>>>> >>>>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>>>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>>>> >>>>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>>>> >>>>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>>>> >>>>>>> /subsystem=messaging/ >>>>>>> hornetq-server=*/ >>>>>>> ha-policy=live-only >>>>>>> ha-policy=replicated-master >>>>>>> ha-policy=replicated-slave >>>>>>> ha-policy=replicated-colocated >>>>>>> ha-policy=shared-store-master >>>>>>> ha-policy=shared-store-slave >>>>>>> ha-policy=shared-store-colocated >>>>>>> >>>>>>> I have constraints for this ha-policy resource: >>>>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>>>> >>>>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>>>> >>>>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>>>> >>>>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>>>> >>>>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>>>> >>>>>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>>>> { >>>>>>> "outcome" => "success", >>>>>>> "result" => [ >>>>>>> { >>>>>>> "address" => [ >>>>>>> ("subsystem" => "messaging"), >>>>>>> ("hornetq-server" => "default"), >>>>>>> ("ha-policy" => "replication-colocated") >>>>>>> ], >>>>>>> "outcome" => "success", >>>>>>> "result" => { >>>>>>> ... >>>>>>> } >>>>>>> }, >>>>>>> { >>>>>>> "address" => [ >>>>>>> ("subsystem" => "messaging"), >>>>>>> ("hornetq-server" => "default"), >>>>>>> ("ha-policy" => "replication-master") >>>>>>> ], >>>>>>> "outcome" => "success", >>>>>>> "result" => { >>>>>>> ... >>>>>>> } >>>>>>> }, >>>>>>> { >>>>>>> "address" => [ >>>>>>> ("subsystem" => "messaging"), >>>>>>> ("hornetq-server" => "default"), >>>>>>> ("ha-policy" => "shared-store-slave") >>>>>>> ], >>>>>>> "outcome" => "success", >>>>>>> "result" => { >>>>>>> ... >>>>>>> } >>>>>>> }, >>>>>>> { >>>>>>> "address" => [ >>>>>>> ("subsystem" => "messaging"), >>>>>>> ("hornetq-server" => "default"), >>>>>>> ("ha-policy" => "live-only") >>>>>>> ], >>>>>>> "outcome" => "success", >>>>>>> "result" => { >>>>>>> ... >>>>>>> } >>>>>>> }, >>>>>>> { >>>>>>> "address" => [ >>>>>>> ("subsystem" => "messaging"), >>>>>>> ("hornetq-server" => "default"), >>>>>>> ("ha-policy" => "shared-store-master") >>>>>>> ], >>>>>>> "outcome" => "success", >>>>>>> "result" => { >>>>>>> ... >>>>>>> } >>>>>>> }, >>>>>>> { >>>>>>> "address" => [ >>>>>>> ("subsystem" => "messaging"), >>>>>>> ("hornetq-server" => "default"), >>>>>>> ("ha-policy" => "replication-slave") >>>>>>> ], >>>>>>> "outcome" => "success", >>>>>>> "result" => { >>>>>>> ... >>>>>>> } >>>>>>> }, >>>>>>> { >>>>>>> "address" => [ >>>>>>> ("subsystem" => "messaging"), >>>>>>> ("hornetq-server" => "default"), >>>>>>> ("ha-policy" => "shared-store-colocated") >>>>>>> ], >>>>>>> "outcome" => "success", >>>>>>> "result" => { >>>>>>> ... >>>>>>> } >>>>>>> } >>>>>>> ] >>>>>>> } >>>>>>> >>>>>>> jeff >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> 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 > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Thu Oct 30 11:16:43 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 30 Oct 2014 10:16:43 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <3EE5F2EC-FDA4-4524-8F5F-3FE43182968A@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <54523852.1070908@redhat.com> <545240AB.3060705@redhat.com> <54524403.1080805@redhat.com> <54524468.2080404@redhat.com> <6BB822B2-F68D-4197-A9BE-19ED9007FB4B@redhat.com> <3EE5F2EC-FDA4-4524-8F5F-3FE43182968A@redhat.com> Message-ID: <5452565B.9000003@redhat.com> I shouldn't have mentioned min/max, as my only point was that it was a crusty thing out there that doesn't really address the problem. In this case, yes, there could be a 1:1 address to name relationship, but there is nothing in our metadata that describes that only one of those addresses can legally exist in a given tree. We have an "alternatives" description for the requirement for a choice amongst attributes, but nothing like that for resources. On 10/30/14, 9:15 AM, Jason Greene wrote: > Wow I am error-prone in the morning! > > "1:1 address to name relationship? > > -> 1:1 address to description relationship > > "/subsystem=messaging=*:read-resource-definition? > > -> subsystem=messaging=*:read-resource-description > >> On Oct 30, 2014, at 9:12 AM, Jason Greene wrote: >> >> It sounds like in this case min/max is unnecessary because of the 1:1 address to name relationship. I think Jeff?s case is easily solved by returning fully qualified address based resource definitions. For example, if you do: >> >> /subsystem=messaging=*:read-resource-definition >> >> If the result contained nested N sets of resource definitions, as previously discussed, it?s all pretty straight forward. >> >> >>> On Oct 30, 2014, at 9:00 AM, Brian Stansberry wrote: >>> >>> I'm not so sure that bad idea was yours. >>> >>> But +1 on getting rid of the existing min/max thing. >>> >>> On 10/30/14, 8:58 AM, David M. Lloyd wrote: >>>> Using schema-ish things like min/max was probably a bad idea on my part. >>>> After trying to model XML schema in various ways for various reasons >>>> over the years, I know now that the simpler our rules are, the easier it >>>> will be to implement a cohesive and useful UX. >>>> >>>> IMO any currently unused and un-useful constructs like this that are >>>> hanging around probably need to be pruned, before someone actually uses >>>> them and makes everyone's live more difficult. :-) >>>> >>>> On 10/30/2014 08:44 AM, Brian Stansberry wrote: >>>>> No, we don't. That currently would have to be handled in a custom way by >>>>> the OSH that does the add for any of the children. >>>>> >>>>> There are some bits and pieces in the metadata that can help with doing >>>>> some sort of automated validation (i.e. a currently basically unused >>>>> max/min child count thing) but I don't think what's there is sufficient. >>>>> >>>>> The fact the metadata isn't there means a client like the console >>>>> couldn't enforce the constraint server side, for a better UX. >>>>> >>>>> On 10/30/14, 8:08 AM, David M. Lloyd wrote: >>>>>> I mean, a single child where there can be many possible types for that >>>>>> child. >>>>>> >>>>>> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>>>>>> I think that polymorphism is a new use case for 'squatters'. I wonder >>>>>>> if we have any existing code which enforces single children? >>>>>>> >>>>>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>>>>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>>>>> >>>>>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>>>>> >>>>>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>>>>> >>>>>>>> /subsystem=messaging/ >>>>>>>> hornetq-server=*/ >>>>>>>> ha-policy=live-only >>>>>>>> ha-policy=replicated-master >>>>>>>> ha-policy=replicated-slave >>>>>>>> ha-policy=replicated-colocated >>>>>>>> ha-policy=shared-store-master >>>>>>>> ha-policy=shared-store-slave >>>>>>>> ha-policy=shared-store-colocated >>>>>>>> >>>>>>>> I have constraints for this ha-policy resource: >>>>>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>>>>> >>>>>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>>>>> >>>>>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>>>>> >>>>>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>>>>> >>>>>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>>>>> >>>>>>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>>>>> { >>>>>>>> "outcome" => "success", >>>>>>>> "result" => [ >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "replication-colocated") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "replication-master") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "shared-store-slave") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "live-only") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "shared-store-master") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "replication-slave") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> }, >>>>>>>> { >>>>>>>> "address" => [ >>>>>>>> ("subsystem" => "messaging"), >>>>>>>> ("hornetq-server" => "default"), >>>>>>>> ("ha-policy" => "shared-store-colocated") >>>>>>>> ], >>>>>>>> "outcome" => "success", >>>>>>>> "result" => { >>>>>>>> ... >>>>>>>> } >>>>>>>> } >>>>>>>> ] >>>>>>>> } >>>>>>>> >>>>>>>> jeff >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> 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 >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > > -- > 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 david.lloyd at redhat.com Thu Oct 30 11:23:55 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 30 Oct 2014 10:23:55 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> Message-ID: <5452580B.8060703@redhat.com> The main advantage of polymorphism (which is really just a way of saying "decoupling model location from node type") is (perhaps obviously) that you can use the same model location for more than one type. This means that user interface frameworks (for example) could know that there is only one possible sub-resource address, say "service=ha-policy" (to use Heiko's original naming example mixed with Jeff's practical example). Then it only has to make a decision as to how to render the resource, rather than having to analyze the model to know that, of the six possible children for "ha-policy", only one can ever be present. On 10/30/2014 09:06 AM, Jason Greene wrote: > Is it really polymorphism though if you do not share attributes or operations? > > It sounds like these are all distinct types just sharing the same portion of an address. > > The primary justification for this modeling approach seems to be: > > 1) Avoid the user having to assign a name > 2) Enforce a single occurrence of a ?type? > > >> On Oct 30, 2014, at 8:01 AM, David M. Lloyd wrote: >> >> I think that polymorphism is a new use case for 'squatters'. I wonder >> if we have any existing code which enforces single children? >> >> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>> >>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>> >>> To represent this in the management model, I have added several resources under hornetq-server: >>> >>> /subsystem=messaging/ >>> hornetq-server=*/ >>> ha-policy=live-only >>> ha-policy=replicated-master >>> ha-policy=replicated-slave >>> ha-policy=replicated-colocated >>> ha-policy=shared-store-master >>> ha-policy=shared-store-slave >>> ha-policy=shared-store-colocated >>> >>> I have constraints for this ha-policy resource: >>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>> >>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>> >>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>> >>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>> >>> Heiko, is it something that would make sense for the console based on this resource description: >>> >>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>> { >>> "outcome" => "success", >>> "result" => [ >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "live-only") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> } >>> ] >>> } >>> >>> jeff >>> >> >> -- >> - DML >> _______________________________________________ >> 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 > -- - DML From jason.greene at redhat.com Thu Oct 30 11:30:19 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 30 Oct 2014 10:30:19 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <5452565B.9000003@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <54523852.1070908@redhat.com> <545240AB.3060705@redhat.com> <54524403.1080805@redhat.com> <54524468.2080404@redhat.com> <6BB822B2-F68D-4197-A9BE-19ED9007FB4B@redhat.com> <3EE5F2EC-FDA4-4524-8F5F-3FE43182968A@redhat.com> <5452565B.9000003@redhat.com> Message-ID: <91918254-DF78-4DA0-BA32-C105B3DD819F@redhat.com> Ah yes I missed that. I?ll say more in my reply to David. > On Oct 30, 2014, at 10:16 AM, Brian Stansberry wrote: > > I shouldn't have mentioned min/max, as my only point was that it was a crusty thing out there that doesn't really address the problem. > > In this case, yes, there could be a 1:1 address to name relationship, but there is nothing in our metadata that describes that only one of those addresses can legally exist in a given tree. > > We have an "alternatives" description for the requirement for a choice amongst attributes, but nothing like that for resources. > > On 10/30/14, 9:15 AM, Jason Greene wrote: >> Wow I am error-prone in the morning! >> >> "1:1 address to name relationship? >> >> -> 1:1 address to description relationship >> >> "/subsystem=messaging=*:read-resource-definition? >> >> -> subsystem=messaging=*:read-resource-description >> >>> On Oct 30, 2014, at 9:12 AM, Jason Greene wrote: >>> >>> It sounds like in this case min/max is unnecessary because of the 1:1 address to name relationship. I think Jeff?s case is easily solved by returning fully qualified address based resource definitions. For example, if you do: >>> >>> /subsystem=messaging=*:read-resource-definition >>> >>> If the result contained nested N sets of resource definitions, as previously discussed, it?s all pretty straight forward. >>> >>> >>>> On Oct 30, 2014, at 9:00 AM, Brian Stansberry wrote: >>>> >>>> I'm not so sure that bad idea was yours. >>>> >>>> But +1 on getting rid of the existing min/max thing. >>>> >>>> On 10/30/14, 8:58 AM, David M. Lloyd wrote: >>>>> Using schema-ish things like min/max was probably a bad idea on my part. >>>>> After trying to model XML schema in various ways for various reasons >>>>> over the years, I know now that the simpler our rules are, the easier it >>>>> will be to implement a cohesive and useful UX. >>>>> >>>>> IMO any currently unused and un-useful constructs like this that are >>>>> hanging around probably need to be pruned, before someone actually uses >>>>> them and makes everyone's live more difficult. :-) >>>>> >>>>> On 10/30/2014 08:44 AM, Brian Stansberry wrote: >>>>>> No, we don't. That currently would have to be handled in a custom way by >>>>>> the OSH that does the add for any of the children. >>>>>> >>>>>> There are some bits and pieces in the metadata that can help with doing >>>>>> some sort of automated validation (i.e. a currently basically unused >>>>>> max/min child count thing) but I don't think what's there is sufficient. >>>>>> >>>>>> The fact the metadata isn't there means a client like the console >>>>>> couldn't enforce the constraint server side, for a better UX. >>>>>> >>>>>> On 10/30/14, 8:08 AM, David M. Lloyd wrote: >>>>>>> I mean, a single child where there can be many possible types for that >>>>>>> child. >>>>>>> >>>>>>> On 10/30/2014 08:01 AM, David M. Lloyd wrote: >>>>>>>> I think that polymorphism is a new use case for 'squatters'. I wonder >>>>>>>> if we have any existing code which enforces single children? >>>>>>>> >>>>>>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>>>>>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>>>>>> >>>>>>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>>>>>> >>>>>>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>>>>>> >>>>>>>>> /subsystem=messaging/ >>>>>>>>> hornetq-server=*/ >>>>>>>>> ha-policy=live-only >>>>>>>>> ha-policy=replicated-master >>>>>>>>> ha-policy=replicated-slave >>>>>>>>> ha-policy=replicated-colocated >>>>>>>>> ha-policy=shared-store-master >>>>>>>>> ha-policy=shared-store-slave >>>>>>>>> ha-policy=shared-store-colocated >>>>>>>>> >>>>>>>>> I have constraints for this ha-policy resource: >>>>>>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>>>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>>>>>> >>>>>>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>>>>>> >>>>>>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>>>>>> >>>>>>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>>>>>> >>>>>>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>>>>>> >>>>>>>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>>>>>> { >>>>>>>>> "outcome" => "success", >>>>>>>>> "result" => [ >>>>>>>>> { >>>>>>>>> "address" => [ >>>>>>>>> ("subsystem" => "messaging"), >>>>>>>>> ("hornetq-server" => "default"), >>>>>>>>> ("ha-policy" => "replication-colocated") >>>>>>>>> ], >>>>>>>>> "outcome" => "success", >>>>>>>>> "result" => { >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> }, >>>>>>>>> { >>>>>>>>> "address" => [ >>>>>>>>> ("subsystem" => "messaging"), >>>>>>>>> ("hornetq-server" => "default"), >>>>>>>>> ("ha-policy" => "replication-master") >>>>>>>>> ], >>>>>>>>> "outcome" => "success", >>>>>>>>> "result" => { >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> }, >>>>>>>>> { >>>>>>>>> "address" => [ >>>>>>>>> ("subsystem" => "messaging"), >>>>>>>>> ("hornetq-server" => "default"), >>>>>>>>> ("ha-policy" => "shared-store-slave") >>>>>>>>> ], >>>>>>>>> "outcome" => "success", >>>>>>>>> "result" => { >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> }, >>>>>>>>> { >>>>>>>>> "address" => [ >>>>>>>>> ("subsystem" => "messaging"), >>>>>>>>> ("hornetq-server" => "default"), >>>>>>>>> ("ha-policy" => "live-only") >>>>>>>>> ], >>>>>>>>> "outcome" => "success", >>>>>>>>> "result" => { >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> }, >>>>>>>>> { >>>>>>>>> "address" => [ >>>>>>>>> ("subsystem" => "messaging"), >>>>>>>>> ("hornetq-server" => "default"), >>>>>>>>> ("ha-policy" => "shared-store-master") >>>>>>>>> ], >>>>>>>>> "outcome" => "success", >>>>>>>>> "result" => { >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> }, >>>>>>>>> { >>>>>>>>> "address" => [ >>>>>>>>> ("subsystem" => "messaging"), >>>>>>>>> ("hornetq-server" => "default"), >>>>>>>>> ("ha-policy" => "replication-slave") >>>>>>>>> ], >>>>>>>>> "outcome" => "success", >>>>>>>>> "result" => { >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> }, >>>>>>>>> { >>>>>>>>> "address" => [ >>>>>>>>> ("subsystem" => "messaging"), >>>>>>>>> ("hornetq-server" => "default"), >>>>>>>>> ("ha-policy" => "shared-store-colocated") >>>>>>>>> ], >>>>>>>>> "outcome" => "success", >>>>>>>>> "result" => { >>>>>>>>> ... >>>>>>>>> } >>>>>>>>> } >>>>>>>>> ] >>>>>>>>> } >>>>>>>>> >>>>>>>>> jeff >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >> >> -- >> 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 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From david.lloyd at redhat.com Thu Oct 30 11:33:58 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 30 Oct 2014 10:33:58 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <5452580B.8060703@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <5452580B.8060703@redhat.com> Message-ID: <54525A66.7010602@redhat.com> At least that's the advantage for this particular use case. Another advantage that I feel I cannot possibly overstate is, it elegantly solves our Elytron authentication client configuration problem without requiring resource sequences. We can have a list of attribute polymorphic groups instead. On 10/30/2014 10:23 AM, David M. Lloyd wrote: > The main advantage of polymorphism (which is really just a way of saying > "decoupling model location from node type") is (perhaps obviously) that > you can use the same model location for more than one type. > > This means that user interface frameworks (for example) could know that > there is only one possible sub-resource address, say "service=ha-policy" > (to use Heiko's original naming example mixed with Jeff's practical > example). Then it only has to make a decision as to how to render the > resource, rather than having to analyze the model to know that, of the > six possible children for "ha-policy", only one can ever be present. > > On 10/30/2014 09:06 AM, Jason Greene wrote: >> Is it really polymorphism though if you do not share attributes or operations? >> >> It sounds like these are all distinct types just sharing the same portion of an address. >> >> The primary justification for this modeling approach seems to be: >> >> 1) Avoid the user having to assign a name >> 2) Enforce a single occurrence of a ?type? >> >> >>> On Oct 30, 2014, at 8:01 AM, David M. Lloyd wrote: >>> >>> I think that polymorphism is a new use case for 'squatters'. I wonder >>> if we have any existing code which enforces single children? >>> >>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>> >>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>> >>>> To represent this in the management model, I have added several resources under hornetq-server: >>>> >>>> /subsystem=messaging/ >>>> hornetq-server=*/ >>>> ha-policy=live-only >>>> ha-policy=replicated-master >>>> ha-policy=replicated-slave >>>> ha-policy=replicated-colocated >>>> ha-policy=shared-store-master >>>> ha-policy=shared-store-slave >>>> ha-policy=shared-store-colocated >>>> >>>> I have constraints for this ha-policy resource: >>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>> >>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>> >>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>> >>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>> >>>> Heiko, is it something that would make sense for the console based on this resource description: >>>> >>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>> { >>>> "outcome" => "success", >>>> "result" => [ >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "live-only") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> } >>>> ] >>>> } >>>> >>>> jeff >>>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> 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 >> > -- - DML From arun.gupta at gmail.com Thu Oct 30 11:34:46 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Thu, 30 Oct 2014 08:34:46 -0700 Subject: [wildfly-dev] Fwd: [Miles to go 2.0 ...] Comment: "WildFly 8 Clustering and Session Failover (Tech Tip #16)" In-Reply-To: <6ec6dc4b12b4c2cbc94602178e32e748@blog.arungupta.me> References: <6ec6dc4b12b4c2cbc94602178e32e748@blog.arungupta.me> Message-ID: A user is trying to upgrade from JBoss to WildFly and facing the error. He also posted the question on forum and waiting for a response. Can somebody please follow up on either forum or my blog ? Let me know so that I can close the loop on my blog at least. ---------- Forwarded message ---------- From: Schuller Tom Date: Thu, Oct 30, 2014 at 6:14 AM Subject: [Miles to go 2.0 ...] Comment: "WildFly 8 Clustering and Session Failover (Tech Tip #16)" To: arun.gupta at gmail.com New comment on your post "WildFly 8 Clustering and Session Failover (Tech Tip #16)" Author : Schuller Tom (IP: 194.154.205.47 , proxy.etat.lu) E-mail : tom at schuller.lu URL : Whois : http://whois.arin.net/rest/ip/194.154.205.47 Comment: Hi Arun, we wanted to upgrade our JBoss7 servers to wildfly. But we have problem during our "logout" action where we are invalidating the sessions. While a long-running conversation is started and we are invalidating the session, we are getting exceptions and the WildFly server is completly blocked. We need to restart it. Exception is always thrown with WildFly version 8.1 and 9.0alpha1. Also the hudson build #1439 ip to #1449 are not working. But using the HudsonBuild #1334, everything is working as expected. We have already posted in the forums, but didn't yet got an anwer: https://developer.jboss.org/thread/249822 The forum post has a link to a demo war where we can reproduce the problem. Thanks for any help, Tom You can see all comments on this post here: http://blog.arungupta.me/2014/03/wildfly-8-clustering-and-session-failover/#comments Permalink: http://blog.arungupta.me/2014/03/wildfly-8-clustering-and-session-failover/comment-page-1/#comment-71066 Trash it: http://blog.arungupta.me/wp-admin/comment.php?action=trash&c=71066 Spam it: http://blog.arungupta.me/wp-admin/comment.php?action=spam&c=71066 -- http://blog.arungupta.me http://twitter.com/arungupta From jason.greene at redhat.com Thu Oct 30 11:46:24 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 30 Oct 2014 10:46:24 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <5452580B.8060703@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <5452580B.8060703@redhat.com> Message-ID: <7E483B9A-E54D-425B-B572-BC9C4AE41121@redhat.com> So the key thing I missed was modeling exclusivity has to apply to the collection of possible types. This could be a polymorphic relationship or just a substitution group like notion (similar to ALTERNATIVES). When you say ?same model location for more than one type?, do you mean multiple types for a fully qualified address (e.g. datasource=awesomeness can have say 3 possible types)? If so I think the complexity goes up quite a bit since you need that additional type specifier. I would like to better understand use-cases where that would becomes important. > On Oct 30, 2014, at 10:23 AM, David M. Lloyd wrote: > > The main advantage of polymorphism (which is really just a way of saying > "decoupling model location from node type") is (perhaps obviously) that > you can use the same model location for more than one type. > > This means that user interface frameworks (for example) could know that > there is only one possible sub-resource address, say "service=ha-policy" > (to use Heiko's original naming example mixed with Jeff's practical > example). Then it only has to make a decision as to how to render the > resource, rather than having to analyze the model to know that, of the > six possible children for "ha-policy", only one can ever be present. > > On 10/30/2014 09:06 AM, Jason Greene wrote: >> Is it really polymorphism though if you do not share attributes or operations? >> >> It sounds like these are all distinct types just sharing the same portion of an address. >> >> The primary justification for this modeling approach seems to be: >> >> 1) Avoid the user having to assign a name >> 2) Enforce a single occurrence of a ?type? >> >> >>> On Oct 30, 2014, at 8:01 AM, David M. Lloyd wrote: >>> >>> I think that polymorphism is a new use case for 'squatters'. I wonder >>> if we have any existing code which enforces single children? >>> >>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>> >>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>> >>>> To represent this in the management model, I have added several resources under hornetq-server: >>>> >>>> /subsystem=messaging/ >>>> hornetq-server=*/ >>>> ha-policy=live-only >>>> ha-policy=replicated-master >>>> ha-policy=replicated-slave >>>> ha-policy=replicated-colocated >>>> ha-policy=shared-store-master >>>> ha-policy=shared-store-slave >>>> ha-policy=shared-store-colocated >>>> >>>> I have constraints for this ha-policy resource: >>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>> >>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>> >>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>> >>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>> >>>> Heiko, is it something that would make sense for the console based on this resource description: >>>> >>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>> { >>>> "outcome" => "success", >>>> "result" => [ >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "live-only") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> } >>>> ] >>>> } >>>> >>>> jeff >>>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> 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 >> > > -- > - DML > _______________________________________________ > 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 Thu Oct 30 11:51:14 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 30 Oct 2014 16:51:14 +0100 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> Message-ID: <2BB528DA-9AAB-4EB5-9A3D-2089B37EE4C4@redhat.com> I agree with jason. I think 'polymorphism' is a misleading term. The child resources are distinct types. On 30 Oct 2014, at 15:06, Jason Greene wrote: > Is it really polymorphism though if you do not share attributes or operations? > > It sounds like these are all distinct types just sharing the same portion of an address. > > The primary justification for this modeling approach seems to be: > > 1) Avoid the user having to assign a name > 2) Enforce a single occurrence of a ?type? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141030/2d4137d4/attachment.html From brian.stansberry at redhat.com Thu Oct 30 12:07:19 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 30 Oct 2014 11:07:19 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <5452580B.8060703@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <5452580B.8060703@redhat.com> Message-ID: <54526237.5030000@redhat.com> On 10/30/14, 10:23 AM, David M. Lloyd wrote: > The main advantage of polymorphism (which is really just a way of saying > "decoupling model location from node type") is (perhaps obviously) that > you can use the same model location for more than one type. > There's a separate branch of this thread that looks to be getting into discussing use cases for polymorphism, so here I'll focus on details a bit. Right now our types are tied to addresses. The address defines the type, and is used to find the description of the type. This is even true with complex attributes, just with a slightly different mechanism. To get away from having the address define the type, we would need some other mechanism for declaring a type. In a hangout today, we brainstormed about using special attributes[1] in any complex ModelNode (i.e. any resource or a complex attribute of OBJECT type). We'd need some clear mechanism for resolving type definitions based on the data in those special attributes. The description of the parent would have to declare what the valid types are, in some combination with what the valid addresses are. That would allow tooling like the console to guide the user when creating new items or radically changing existing ones. For something like the CLI it gets more cumbersome, as our UX (which I like a lot) is based on tab completion. Tab completion could still suggest a type, but the user's choice would no longer get recorded in the current input. This is quite a bit more flexible than the current approach, but also a fair bit more cumbersome for the many cases where there's no need for polymorphism, so the use case discussion is important. [1] We discussed using ".xxx" e.g. ".type" and ".namespace", with attributes whose names begin with the "." prefix becoming reserved. The '.' is kind of nice because it's intuitively like a hidden file on a filesystem, and if we use dot syntax to separate between levels in a complex attribute or between an attribute group and an item, this case fits in. > This means that user interface frameworks (for example) could know that > there is only one possible sub-resource address, say "service=ha-policy" > (to use Heiko's original naming example mixed with Jeff's practical > example). Then it only has to make a decision as to how to render the > resource, rather than having to analyze the model to know that, of the > six possible children for "ha-policy", only one can ever be present. > > On 10/30/2014 09:06 AM, Jason Greene wrote: >> Is it really polymorphism though if you do not share attributes or operations? >> >> It sounds like these are all distinct types just sharing the same portion of an address. >> >> The primary justification for this modeling approach seems to be: >> >> 1) Avoid the user having to assign a name >> 2) Enforce a single occurrence of a ?type? >> >> >>> On Oct 30, 2014, at 8:01 AM, David M. Lloyd wrote: >>> >>> I think that polymorphism is a new use case for 'squatters'. I wonder >>> if we have any existing code which enforces single children? >>> >>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>> >>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>> >>>> To represent this in the management model, I have added several resources under hornetq-server: >>>> >>>> /subsystem=messaging/ >>>> hornetq-server=*/ >>>> ha-policy=live-only >>>> ha-policy=replicated-master >>>> ha-policy=replicated-slave >>>> ha-policy=replicated-colocated >>>> ha-policy=shared-store-master >>>> ha-policy=shared-store-slave >>>> ha-policy=shared-store-colocated >>>> >>>> I have constraints for this ha-policy resource: >>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>> >>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>> >>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>> >>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>> >>>> Heiko, is it something that would make sense for the console based on this resource description: >>>> >>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>> { >>>> "outcome" => "success", >>>> "result" => [ >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "live-only") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> } >>>> ] >>>> } >>>> >>>> jeff >>>> >>> >>> -- >>> - DML >>> _______________________________________________ >>> 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 hbraun at redhat.com Thu Oct 30 12:14:43 2014 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 30 Oct 2014 17:14:43 +0100 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <54526237.5030000@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <5452580B.8060703@redhat.com> <54526237.5030000@redhat.com> Message-ID: Thanks for the explanation Brian. On 30 Oct 2014, at 17:07, Brian Stansberry wrote: > There's a separate branch of this thread that looks to be getting into > discussing use cases for polymorphism, so here I'll focus on details a bit. > > Right now our types are tied to addresses. The address defines the type, > and is used to find the description of the type. This is even true with > complex attributes, just with a slightly different mechanism. > > To get away from having the address define the type, we would need some > other mechanism for declaring a type. In a hangout today, we > brainstormed about using special attributes[1] in any complex ModelNode > (i.e. any resource or a complex attribute of OBJECT type). > > We'd need some clear mechanism for resolving type definitions based on > the data in those special attributes. > > The description of the parent would have to declare what the valid types > are, in some combination with what the valid addresses are. That would > allow tooling like the console to guide the user when creating new items > or radically changing existing ones. > > For something like the CLI it gets more cumbersome, as our UX (which I > like a lot) is based on tab completion. Tab completion could still > suggest a type, but the user's choice would no longer get recorded in > the current input. > > This is quite a bit more flexible than the current approach, but also a > fair bit more cumbersome for the many cases where there's no need for > polymorphism, so the use case discussion is important. > > > [1] We discussed using ".xxx" e.g. ".type" and ".namespace", with > attributes whose names begin with the "." prefix becoming reserved. The > '.' is kind of nice because it's intuitively like a hidden file on a > filesystem, and if we use dot syntax to separate between levels in a > complex attribute or between an attribute group and an item, this case > fits in. > >> This means that user interface frameworks (for example) could know that >> there is only one possible sub-resource address, say "service=ha-policy" >> (to use Heiko's original naming example mixed with Jeff's practical >> example). Then it only has to make a decision as to how to render the >> resource, rather than having to analyze the model to know that, of the >> six possible children for "ha-policy", only one can ever be present. >> >> On 10/30/2014 09:06 AM, Jason Greene wrote: >>> Is it really polymorphism though if you do not share attributes or operations? >>> >>> It sounds like these are all distinct types just sharing the same portion of an address. >>> >>> The primary justification for this modeling approach seems to be: >>> >>> 1) Avoid the user having to assign a name >>> 2) Enforce a single occurrence of a ?type? >>> >>> >>>> On Oct 30, 2014, at 8:01 AM, David M. Lloyd wrote: >>>> >>>> I think that polymorphism is a new use case for 'squatters'. I wonder >>>> if we have any existing code which enforces single children? >>>> >>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>> >>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>> >>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>> >>>>> /subsystem=messaging/ >>>>> hornetq-server=*/ >>>>> ha-policy=live-only >>>>> ha-policy=replicated-master >>>>> ha-policy=replicated-slave >>>>> ha-policy=replicated-colocated >>>>> ha-policy=shared-store-master >>>>> ha-policy=shared-store-slave >>>>> ha-policy=shared-store-colocated >>>>> >>>>> I have constraints for this ha-policy resource: >>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>> >>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>> >>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>> >>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>> >>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>> >>>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>> { >>>>> "outcome" => "success", >>>>> "result" => [ >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-colocated") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-master") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-slave") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "live-only") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-master") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-slave") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-colocated") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> } >>>>> ] >>>>> } >>>>> >>>>> jeff >>>>> >>>> >>>> -- >>>> - DML >>>> _______________________________________________ >>>> 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 >>> >> > > > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141030/91384920/attachment-0001.html From brian.stansberry at redhat.com Thu Oct 30 12:29:10 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 30 Oct 2014 11:29:10 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <54526237.5030000@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <54523695.2090409@redhat.com> <5452580B.8060703@redhat.com> <54526237.5030000@redhat.com> Message-ID: <54526756.9030409@redhat.com> On 10/30/14, 11:07 AM, Brian Stansberry wrote: > On 10/30/14, 10:23 AM, David M. Lloyd wrote: >> The main advantage of polymorphism (which is really just a way of saying >> "decoupling model location from node type") is (perhaps obviously) that >> you can use the same model location for more than one type. >> > > There's a separate branch of this thread that looks to be getting into > discussing use cases for polymorphism, so here I'll focus on details a bit. > > Right now our types are tied to addresses. The address defines the type, > and is used to find the description of the type. This is even true with > complex attributes, just with a slightly different mechanism. > > To get away from having the address define the type, we would need some > other mechanism for declaring a type. In a hangout today, we > brainstormed about using special attributes[1] in any complex ModelNode > (i.e. any resource or a complex attribute of OBJECT type). > > We'd need some clear mechanism for resolving type definitions based on > the data in those special attributes. > > The description of the parent would have to declare what the valid types > are, in some combination with what the valid addresses are. That would > allow tooling like the console to guide the user when creating new items > or radically changing existing ones. > > For something like the CLI it gets more cumbersome, as our UX (which I > like a lot) is based on tab completion. Tab completion could still > suggest a type, but the user's choice would no longer get recorded in > the current input. > This may be less of an issue than I thought. If polymorphism is allowed, the operation sent to the server will need to identify the type too, presumably as a param. So that tab completion data will get recorded in the input, like all the current cases. The special behavior here is when polymorphism is allowed, the initial tab completion will have to only allow choices that define the intended type. Once that is known, the rest proceeds as it does now. > This is quite a bit more flexible than the current approach, but also a > fair bit more cumbersome for the many cases where there's no need for > polymorphism, so the use case discussion is important. > > > [1] We discussed using ".xxx" e.g. ".type" and ".namespace", with > attributes whose names begin with the "." prefix becoming reserved. The > '.' is kind of nice because it's intuitively like a hidden file on a > filesystem, and if we use dot syntax to separate between levels in a > complex attribute or between an attribute group and an item, this case > fits in. > >> This means that user interface frameworks (for example) could know that >> there is only one possible sub-resource address, say "service=ha-policy" >> (to use Heiko's original naming example mixed with Jeff's practical >> example). Then it only has to make a decision as to how to render the >> resource, rather than having to analyze the model to know that, of the >> six possible children for "ha-policy", only one can ever be present. >> >> On 10/30/2014 09:06 AM, Jason Greene wrote: >>> Is it really polymorphism though if you do not share attributes or operations? >>> >>> It sounds like these are all distinct types just sharing the same portion of an address. >>> >>> The primary justification for this modeling approach seems to be: >>> >>> 1) Avoid the user having to assign a name >>> 2) Enforce a single occurrence of a ?type? >>> >>> >>>> On Oct 30, 2014, at 8:01 AM, David M. Lloyd wrote: >>>> >>>> I think that polymorphism is a new use case for 'squatters'. I wonder >>>> if we have any existing code which enforces single children? >>>> >>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote: >>>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>> >>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>> >>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>> >>>>> /subsystem=messaging/ >>>>> hornetq-server=*/ >>>>> ha-policy=live-only >>>>> ha-policy=replicated-master >>>>> ha-policy=replicated-slave >>>>> ha-policy=replicated-colocated >>>>> ha-policy=shared-store-master >>>>> ha-policy=shared-store-slave >>>>> ha-policy=shared-store-colocated >>>>> >>>>> I have constraints for this ha-policy resource: >>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>> >>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>> >>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>> >>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>> >>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>> >>>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>> { >>>>> "outcome" => "success", >>>>> "result" => [ >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-colocated") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-master") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-slave") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "live-only") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-master") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-slave") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-colocated") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> } >>>>> ] >>>>> } >>>>> >>>>> jeff >>>>> >>>> >>>> -- >>>> - DML >>>> _______________________________________________ >>>> 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 sstark at redhat.com Thu Oct 30 19:53:54 2014 From: sstark at redhat.com (Scott Stark) Date: Thu, 30 Oct 2014 19:53:54 -0400 (EDT) Subject: [wildfly-dev] Major filesystem change coming in se 9 In-Reply-To: <458445230.2636747.1414713083343.JavaMail.zimbra@redhat.com> Message-ID: <24219025.2637444.1414713234616.JavaMail.zimbra@redhat.com> Perhaps your already aware of this due to it's relation to the module changes being discussed for se 9, but this caught my attention today: http://openjdk.java.net/jeps/220 There is a discussion on the jigsaw list about how this will impact many tools, servers making assumptions about the se filesystem, extension mechanism. From sebastian.laskawiec at gmail.com Fri Oct 31 09:01:34 2014 From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=) Date: Fri, 31 Oct 2014 14:01:34 +0100 Subject: [wildfly-dev] Issues in wildfly-javaee7-webapp-blank-archetype In-Reply-To: References: <5451F693.2070807@redhat.com> Message-ID: Hi Arun! Wildfly archetypes are created based on Quickstarts (just as Rafael mentioned here [1]). In case of *wildfly-**javaee7-webapp-blank-archetype* it is *kitchensink* [1]. Quickstarts are designed in such a way, that they can be deployed all together (this is why they need separate datasources). So, test-ds.xml is a design consequence of how Quickstarts are embedded into archetypes. In my opinion we won't be able to get rid of it. Alternatively we could refactor all quickstarts to use default database - which might be pretty time consuming. Best regards Sebastian [1] https://issues.jboss.org/browse/WFLY-4030?focusedCommentId=13016156 [2] https://github.com/wildfly/quickstart/tree/master/kitchensink 2014-10-30 13:04 GMT+01:00 Arun Gupta : > For Java EE 7, a default data source is available if none is specified > in persistence.xml. In WildFly, this is mapped to ExampleDS already. > > Does test-ds.xml create a new data source, or map to an existing one ? > > Arun > > On Thu, Oct 30, 2014 at 1:28 AM, Sebastian ?askawiec > wrote: > > Hey > > > > I would like to volunteer for WFLY-4030 and a Quickstarts change: > WFLY-4031. > > > > However I'm not sure about removing test-ds.xml. Maybe the point is to > > show how to add DataSources bundled with the application? > > On the other hand if this is not the point - I think we should change it > > to ExampleDS. > > > > What's your opinion on that? > > > > Best regards > > Sebastian > > > > On 10/29/2014 07:54 PM, Arun Gupta wrote: > >> - What is the purpose of test-ds.xml ? It contains: > >> This is anyway the default Java EE 7 data source in WildFly. > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > http://blog.arungupta.me > http://twitter.com/arungupta > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Sebastian ?askawiec -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141031/6fc2b741/attachment.html From arun.gupta at gmail.com Fri Oct 31 09:07:26 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Fri, 31 Oct 2014 13:07:26 +0000 Subject: [wildfly-dev] Issues in wildfly-javaee7-webapp-blank-archetype References: <5451F693.2070807@redhat.com> Message-ID: Default data sources is one of the new features of Java EE 7 and I think its worth showcasing how apps can be simplified with that. I'll let you decide upon resource/time but its useful IMHO. Arun On Fri Oct 31 2014 at 6:01:34 AM Sebastian ?askawiec < sebastian.laskawiec at gmail.com> wrote: > Hi Arun! > > Wildfly archetypes are created based on Quickstarts (just as Rafael > mentioned here [1]). > In case of *wildfly-**javaee7-webapp-blank-archetype* it is *kitchensink* > [1]. Quickstarts are designed in such a way, that they can be deployed all > together (this is why they need separate datasources). > > So, test-ds.xml is a design consequence of how Quickstarts are embedded > into archetypes. In my opinion we won't be able to get rid of it. > Alternatively we could refactor all quickstarts to use default database - > which might be pretty time consuming. > > Best regards > Sebastian > > [1] https://issues.jboss.org/browse/WFLY-4030?focusedCommentId=13016156 > [2] https://github.com/wildfly/quickstart/tree/master/kitchensink > > > 2014-10-30 13:04 GMT+01:00 Arun Gupta : > >> For Java EE 7, a default data source is available if none is specified >> in persistence.xml. In WildFly, this is mapped to ExampleDS already. >> >> Does test-ds.xml create a new data source, or map to an existing one ? >> >> Arun >> >> On Thu, Oct 30, 2014 at 1:28 AM, Sebastian ?askawiec >> wrote: >> > Hey >> > >> > I would like to volunteer for WFLY-4030 and a Quickstarts change: >> WFLY-4031. >> > >> > However I'm not sure about removing test-ds.xml. Maybe the point is to >> > show how to add DataSources bundled with the application? >> > On the other hand if this is not the point - I think we should change it >> > to ExampleDS. >> > >> > What's your opinion on that? >> > >> > Best regards >> > Sebastian >> > >> > On 10/29/2014 07:54 PM, Arun Gupta wrote: >> >> - What is the purpose of test-ds.xml ? It contains: >> >> This is anyway the default Java EE 7 data source in WildFly. >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Sebastian ?askawiec > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141031/4567c95c/attachment-0001.html From hpehl at redhat.com Fri Oct 31 11:35:09 2014 From: hpehl at redhat.com (Harald Pehl) Date: Fri, 31 Oct 2014 16:35:09 +0100 Subject: [wildfly-dev] Map / reduce for management operations Message-ID: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> TL;DR For management clients it is tedious and awkward to read resources / attributes in big domains (e.g. return the state of all running servers across all hosts which are part of server group "foo"). Today this requires to setup multiple composite operations *on the client* which need to be executed in a specific order. This proposal suggests a new operation which collects all relevant information *on the server* and returns only the relevant data in one go to the client. -------------------- # Background: In the admin console we often need to read specific attributes across a domain or across a deeply nested resource: - List all enabled data sources of the current profile - Show the port offset of all running servers across all hosts - Get all users which belong to role Operator Even for small domains with two server groups and a small number of servers this procedure is awkward and error prone. What makes it even more difficult is the asynchronous nature of the admin console. Soon you end up in a deeply nested callback-hell. Besides that these 'queries' lead to poor performance for big domains with tens of groups, hosts and servers. # Proposal / Prototype The GitHub repository at [1] contains a more detailed description of the problem statement and a working prototype. This includes details such as how to address the requested resources, how the information is retrieved and how to handle errors. The proposal also includes a way to filter and reduce the resources against a list of attributes and values *before* the response is sent to the client. [1] https://github.com/hpehl/map-reduce --- 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/20141031/0e470371/attachment.html From ssilvert at redhat.com Fri Oct 31 12:03:23 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 31 Oct 2014 12:03:23 -0400 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> Message-ID: <5453B2CB.9050803@redhat.com> Taken to its logical conclusion, this would become a full-fledged query language. You could just create a client-side library for it and use that as the "language" develops. I think that would be a safe thing to do before committing it as part of the supported server side interface. How much of a problem would this be if it were not for GWT's callback-hell? It's my understanding that GWT is fixing that? On 10/31/2014 11:35 AM, Harald Pehl wrote: > TL;DR > > For management clients it is tedious and awkward to read resources / > attributes in big domains (e.g. return the state of all running > servers across all hosts which are part of server group "foo"). Today > this requires to setup multiple composite operations *on the > client* which need to be executed in a specific order. This proposal > suggests a new operation which collects all relevant information *on > the server* and returns only the relevant data in one go to the client. > > -------------------- > > # Background: > > In the admin console we often need to read specific attributes across > a domain or across a deeply nested resource: > > - List all enabled data sources of the current profile > - Show the port offset of all running servers across all hosts > - Get all users which belong to role Operator > > Even for small domains with two server groups and a small number of > servers this procedure is awkward and error prone. What makes it even > more difficult is the asynchronous nature of the admin console. Soon > you end up in a deeply nested callback-hell. Besides that these > 'queries' lead to poor performance for big domains with tens of > groups, hosts and servers. > > # Proposal / Prototype > > The GitHub repository at [1] contains a more detailed description of > the problem statement and a working prototype. This includes details > such as how to address the requested resources, how the information is > retrieved and how to handle errors. > > The proposal also includes a way to filter and reduce the resources > against a list of attributes and values *before* the response is sent > to the client. > > [1] https://github.com/hpehl/map-reduce > > --- > 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/20141031/ffa8573c/attachment.html From hrupp at redhat.com Fri Oct 31 12:05:15 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 31 Oct 2014 17:05:15 +0100 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> Message-ID: <0A70909E-1543-4BFB-BFD5-0A392F9351FF@redhat.com> > Am 31.10.2014 um 16:35 schrieb Harald Pehl : > composite operations *on the client* which need to be executed in a specific order. This proposal suggests a new operation which collects all relevant information *on the server* and returns only the relevant data in one go to the Awesome, go for it. From hrupp at redhat.com Fri Oct 31 12:05:59 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 31 Oct 2014 17:05:59 +0100 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <5453B2CB.9050803@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> <5453B2CB.9050803@redhat.com> Message-ID: > Am 31.10.2014 um 17:03 schrieb Stan Silvert : > How much of a problem would this be if it were not for GWT's callback-hell? It's my understanding that GWT is fixing that? HAL is not the only client out there that needs that. RHQ/JBoss ON can heavily benefit from that. From brian.stansberry at redhat.com Fri Oct 31 12:48:47 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 31 Oct 2014 11:48:47 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <5870CA2B-A65B-451C-AA3A-8F3B02781FFD@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <5870CA2B-A65B-451C-AA3A-8F3B02781FFD@redhat.com> Message-ID: <5453BD6F.4040806@redhat.com> On 10/30/14, 6:55 AM, Heiko Braun wrote: > > > Thanks for the update Jeff. Yes, it's true that singleton resources impose problem when attempting to further automate (read data binding) the UI components we have in the console. But currently I don't believe we can do without them, as they provide a valid and reasonable way to model certain resources. So, with regard to your proposal, I think the way you approach the new hornetq resources is fine. > > The specific problems we are facing with the UI need to be tackled in general way and breaks down into these questions: > > - how do we (programmatically) identify singleton resources? > - how do we access their resource meta data (:read-resource-desciption)? > > The fundamental problem (as described in my previous email) is that you cannot tell which resources are singletons when walking the tree using any of the child related operations (read-child-types(), read-children-names()). Currently the only way to go about that is to read child resource recursively and compare their structures. For regular, non-singleton resources the address token key (/=/...) denotes the type. > > We would need an equivalent way to identify the types for singleton resources as well. This for instance would work for us: > > /subsystem=messaging/hornetq-sever=*:read-children-types() > { > "outcome" => "success", > "result" => [ > ..., > "ha-policy=live-only", > "ha-policy=replicated-master", > "ha-policy=replicated-slave", > ... > ] > } > I haven't taken action on this specific request before because this general area is a really broad topic and I wanted to let thinking play out. But we've been thinking about it quite a while now and there's a consensus that these singleton resource types exist and there's no reason not to improve the API in this way. I opened https://issues.jboss.org/browse/WFCORE-208 and we'll be sure it's resolved for the WF 9 Beta1. Please have a look at the description of that JIRA, where I'm quite precise about the semantics. > > On 30 Oct 2014, at 11:40, Jeff Mesnil wrote: > >> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >> >> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >> >> To represent this in the management model, I have added several resources under hornetq-server: >> >> /subsystem=messaging/ >> hornetq-server=*/ >> ha-policy=live-only >> ha-policy=replicated-master >> ha-policy=replicated-slave >> ha-policy=replicated-colocated >> ha-policy=shared-store-master >> ha-policy=shared-store-slave >> ha-policy=shared-store-colocated >> >> I have constraints for this ha-policy resource: >> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >> >> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >> >> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >> >> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >> >> Heiko, is it something that would make sense for the console based on this resource description: >> >> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >> { >> "outcome" => "success", >> "result" => [ >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-colocated") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-master") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-slave") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "live-only") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-master") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "replication-slave") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> }, >> { >> "address" => [ >> ("subsystem" => "messaging"), >> ("hornetq-server" => "default"), >> ("ha-policy" => "shared-store-colocated") >> ], >> "outcome" => "success", >> "result" => { >> ... >> } >> } >> ] >> } >> >> jeff >> >> -- >> Jeff Mesnil >> JBoss, a division of Red Hat >> http://jmesnil.net/ >> > > > _______________________________________________ > 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 kabir.khan at jboss.com Fri Oct 31 12:54:40 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Fri, 31 Oct 2014 16:54:40 +0000 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <5453BD6F.4040806@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <5870CA2B-A65B-451C-AA3A-8F3B02781FFD@redhat.com> <5453BD6F.4040806@redhat.com> Message-ID: > On 31 Oct 2014, at 16:48, Brian Stansberry wrote: > > On 10/30/14, 6:55 AM, Heiko Braun wrote: >> >> >> Thanks for the update Jeff. Yes, it's true that singleton resources impose problem when attempting to further automate (read data binding) the UI components we have in the console. But currently I don't believe we can do without them, as they provide a valid and reasonable way to model certain resources. So, with regard to your proposal, I think the way you approach the new hornetq resources is fine. >> >> The specific problems we are facing with the UI need to be tackled in general way and breaks down into these questions: >> >> - how do we (programmatically) identify singleton resources? >> - how do we access their resource meta data (:read-resource-desciption)? >> >> The fundamental problem (as described in my previous email) is that you cannot tell which resources are singletons when walking the tree using any of the child related operations (read-child-types(), read-children-names()). Currently the only way to go about that is to read child resource recursively and compare their structures. For regular, non-singleton resources the address token key (/=/...) denotes the type. >> >> We would need an equivalent way to identify the types for singleton resources as well. This for instance would work for us: >> >> /subsystem=messaging/hornetq-sever=*:read-children-types() >> { >> "outcome" => "success", >> "result" => [ >> ..., >> "ha-policy=live-only", >> "ha-policy=replicated-master", >> "ha-policy=replicated-slave", >> ... >> ] >> } >> > > I haven't taken action on this specific request before because this > general area is a really broad topic and I wanted to let thinking play > out. But we've been thinking about it quite a while now and there's a > consensus that these singleton resource types exist and there's no > reason not to improve the API in this way. > > I opened https://issues.jboss.org/browse/WFCORE-208 and we'll be sure > it's resolved for the WF 9 Beta1. > > Please have a look at the description of that JIRA, where I'm quite > precise about the semantics. That looks very good (and precise!) > >> >> On 30 Oct 2014, at 11:40, Jeff Mesnil wrote: >> >>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>> >>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>> >>> To represent this in the management model, I have added several resources under hornetq-server: >>> >>> /subsystem=messaging/ >>> hornetq-server=*/ >>> ha-policy=live-only >>> ha-policy=replicated-master >>> ha-policy=replicated-slave >>> ha-policy=replicated-colocated >>> ha-policy=shared-store-master >>> ha-policy=shared-store-slave >>> ha-policy=shared-store-colocated >>> >>> I have constraints for this ha-policy resource: >>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>> >>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>> >>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>> >>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>> >>> Heiko, is it something that would make sense for the console based on this resource description: >>> >>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>> { >>> "outcome" => "success", >>> "result" => [ >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "live-only") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-master") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "replication-slave") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> }, >>> { >>> "address" => [ >>> ("subsystem" => "messaging"), >>> ("hornetq-server" => "default"), >>> ("ha-policy" => "shared-store-colocated") >>> ], >>> "outcome" => "success", >>> "result" => { >>> ... >>> } >>> } >>> ] >>> } >>> >>> jeff >>> >>> -- >>> Jeff Mesnil >>> JBoss, a division of Red Hat >>> http://jmesnil.net/ >>> >> >> >> _______________________________________________ >> 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 brian.stansberry at redhat.com Fri Oct 31 13:07:36 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 31 Oct 2014 12:07:36 -0500 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> Message-ID: <5453C1D8.4080202@redhat.com> This would definitely be useful. On the server side we already support a wildcard variant of read-resource. But it only works within a single process, not across processes in the domain. We've never had time to sort that issue. I'd like to see this feature built on a foundation of a proper cross-domain wildcard read-resource. That will kill two birds with one stone, plus ensure consistent behavior. Any other ideas for a name for this? "Map / reduce" to me implies a much broader set of functionality, and I wouldn't want to falsely advertise, nor burn an operation name that we may want later. That also relates to Stan's point in his response, re: this being an element in a broader query feature. If it has a precise name that implies a narrow scope, if later on there is a broader feature that broader feature can co-exist with its ancestor. On 10/31/14, 10:35 AM, Harald Pehl wrote: > TL;DR > > For management clients it is tedious and awkward to read resources / > attributes in big domains (e.g. return the state of all running servers > across all hosts which are part of server group "foo"). Today this > requires to setup multiple composite operations *on the client* which > need to be executed in a specific order. This proposal suggests a new > operation which collects all relevant information *on the > server* and returns only the relevant data in one go to the client. > > -------------------- > > # Background: > > In the admin console we often need to read specific attributes across a > domain or across a deeply nested resource: > > - List all enabled data sources of the current profile > - Show the port offset of all running servers across all hosts > - Get all users which belong to role Operator > > Even for small domains with two server groups and a small number of > servers this procedure is awkward and error prone. What makes it even > more difficult is the asynchronous nature of the admin console. Soon you > end up in a deeply nested callback-hell. Besides that these 'queries' > lead to poor performance for big domains with tens of groups, hosts and > servers. > > # Proposal / Prototype > > The GitHub repository at [1] contains a more detailed description of the > problem statement and a working prototype. This includes details such as > how to address the requested resources, how the information is retrieved > and how to handle errors. > > The proposal also includes a way to filter and reduce the resources > against a list of attributes and values *before* the response is sent to > the client. > > [1] https://github.com/hpehl/map-reduce > > --- > 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 ssilvert at redhat.com Fri Oct 31 13:24:02 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 31 Oct 2014 13:24:02 -0400 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <5870CA2B-A65B-451C-AA3A-8F3B02781FFD@redhat.com> <5453BD6F.4040806@redhat.com> Message-ID: <5453C5B2.3020700@redhat.com> On 10/31/2014 12:54 PM, Kabir Khan wrote: >> On 31 Oct 2014, at 16:48, Brian Stansberry wrote: >> >> On 10/30/14, 6:55 AM, Heiko Braun wrote: >>> >>> Thanks for the update Jeff. Yes, it's true that singleton resources impose problem when attempting to further automate (read data binding) the UI components we have in the console. But currently I don't believe we can do without them, as they provide a valid and reasonable way to model certain resources. So, with regard to your proposal, I think the way you approach the new hornetq resources is fine. >>> >>> The specific problems we are facing with the UI need to be tackled in general way and breaks down into these questions: >>> >>> - how do we (programmatically) identify singleton resources? >>> - how do we access their resource meta data (:read-resource-desciption)? >>> >>> The fundamental problem (as described in my previous email) is that you cannot tell which resources are singletons when walking the tree using any of the child related operations (read-child-types(), read-children-names()). Currently the only way to go about that is to read child resource recursively and compare their structures. For regular, non-singleton resources the address token key (/=/...) denotes the type. >>> >>> We would need an equivalent way to identify the types for singleton resources as well. This for instance would work for us: >>> >>> /subsystem=messaging/hornetq-sever=*:read-children-types() >>> { >>> "outcome" => "success", >>> "result" => [ >>> ..., >>> "ha-policy=live-only", >>> "ha-policy=replicated-master", >>> "ha-policy=replicated-slave", >>> ... >>> ] >>> } >>> >> I haven't taken action on this specific request before because this >> general area is a really broad topic and I wanted to let thinking play >> out. But we've been thinking about it quite a while now and there's a >> consensus that these singleton resource types exist and there's no >> reason not to improve the API in this way. >> >> I opened https://issues.jboss.org/browse/WFCORE-208 and we'll be sure >> it's resolved for the WF 9 Beta1. >> >> Please have a look at the description of that JIRA, where I'm quite >> precise about the semantics. > That looks very good (and precise!) I looked it over carefully and I agree with Kabir. Looks good. It might break CLI GUI, but it shouldn't be hard to deal with that. Please let me know when you've got a prototype working along with a subsystem I can use to test with. >>> On 30 Oct 2014, at 11:40, Jeff Mesnil wrote: >>> >>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>> >>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>> >>>> To represent this in the management model, I have added several resources under hornetq-server: >>>> >>>> /subsystem=messaging/ >>>> hornetq-server=*/ >>>> ha-policy=live-only >>>> ha-policy=replicated-master >>>> ha-policy=replicated-slave >>>> ha-policy=replicated-colocated >>>> ha-policy=shared-store-master >>>> ha-policy=shared-store-slave >>>> ha-policy=shared-store-colocated >>>> >>>> I have constraints for this ha-policy resource: >>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>> >>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>> >>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>> >>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>> >>>> Heiko, is it something that would make sense for the console based on this resource description: >>>> >>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>> { >>>> "outcome" => "success", >>>> "result" => [ >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "live-only") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-master") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "replication-slave") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> }, >>>> { >>>> "address" => [ >>>> ("subsystem" => "messaging"), >>>> ("hornetq-server" => "default"), >>>> ("ha-policy" => "shared-store-colocated") >>>> ], >>>> "outcome" => "success", >>>> "result" => { >>>> ... >>>> } >>>> } >>>> ] >>>> } >>>> >>>> jeff >>>> >>>> -- >>>> Jeff Mesnil >>>> JBoss, a division of Red Hat >>>> http://jmesnil.net/ >>>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Fri Oct 31 13:55:32 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 31 Oct 2014 12:55:32 -0500 Subject: [wildfly-dev] Management Model: Squatter Resources In-Reply-To: <5453C5B2.3020700@redhat.com> References: <4CFC6D7F-6026-4F66-B7A9-0A446CCC8849@redhat.com> <5C879751-80CE-41B9-A342-E3A72AE957B2@jboss.com> <49DE38AA-F904-4A3D-9741-2A9B033672A5@redhat.com> <703DEBF7-76FB-4FEF-983A-4F2D5703C7D1@redhat.com> <5870CA2B-A65B-451C-AA3A-8F3B02781FFD@redhat.com> <5453BD6F.4040806@redhat.com> <5453C5B2.3020700@redhat.com> Message-ID: <5453CD14.5080903@redhat.com> On 10/31/14, 12:24 PM, Stan Silvert wrote: > On 10/31/2014 12:54 PM, Kabir Khan wrote: >>> On 31 Oct 2014, at 16:48, Brian Stansberry wrote: >>> >>> On 10/30/14, 6:55 AM, Heiko Braun wrote: >>>> >>>> Thanks for the update Jeff. Yes, it's true that singleton resources impose problem when attempting to further automate (read data binding) the UI components we have in the console. But currently I don't believe we can do without them, as they provide a valid and reasonable way to model certain resources. So, with regard to your proposal, I think the way you approach the new hornetq resources is fine. >>>> >>>> The specific problems we are facing with the UI need to be tackled in general way and breaks down into these questions: >>>> >>>> - how do we (programmatically) identify singleton resources? >>>> - how do we access their resource meta data (:read-resource-desciption)? >>>> >>>> The fundamental problem (as described in my previous email) is that you cannot tell which resources are singletons when walking the tree using any of the child related operations (read-child-types(), read-children-names()). Currently the only way to go about that is to read child resource recursively and compare their structures. For regular, non-singleton resources the address token key (/=/...) denotes the type. >>>> >>>> We would need an equivalent way to identify the types for singleton resources as well. This for instance would work for us: >>>> >>>> /subsystem=messaging/hornetq-sever=*:read-children-types() >>>> { >>>> "outcome" => "success", >>>> "result" => [ >>>> ..., >>>> "ha-policy=live-only", >>>> "ha-policy=replicated-master", >>>> "ha-policy=replicated-slave", >>>> ... >>>> ] >>>> } >>>> >>> I haven't taken action on this specific request before because this >>> general area is a really broad topic and I wanted to let thinking play >>> out. But we've been thinking about it quite a while now and there's a >>> consensus that these singleton resource types exist and there's no >>> reason not to improve the API in this way. >>> >>> I opened https://issues.jboss.org/browse/WFCORE-208 and we'll be sure >>> it's resolved for the WF 9 Beta1. >>> >>> Please have a look at the description of that JIRA, where I'm quite >>> precise about the semantics. >> That looks very good (and precise!) > I looked it over carefully and I agree with Kabir. Looks good. > > It might break CLI GUI, but it shouldn't be hard to deal with that. > Please let me know when you've got a prototype working along with a > subsystem I can use to test with. The ejb and datasource subsystems are good ones to look at. The "service=remote" / "service=async" examples I used in the JIRA are derived from ejb, while the datasource one is of course from datasources. :) Note the default behavior of the op will be completely unchanged, so any effect on a client would have to be the result of that client allowing the use of the new parameter. >>>> On 30 Oct 2014, at 11:40, Jeff Mesnil wrote: >>>> >>>>> I?m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources. >>>>> >>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated). >>>>> >>>>> To represent this in the management model, I have added several resources under hornetq-server: >>>>> >>>>> /subsystem=messaging/ >>>>> hornetq-server=*/ >>>>> ha-policy=live-only >>>>> ha-policy=replicated-master >>>>> ha-policy=replicated-slave >>>>> ha-policy=replicated-colocated >>>>> ha-policy=shared-store-master >>>>> ha-policy=shared-store-slave >>>>> ha-policy=shared-store-colocated >>>>> >>>>> I have constraints for this ha-policy resource: >>>>> * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage. >>>>> * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail) >>>>> >>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too. >>>>> >>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though. >>>>> >>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource. >>>>> >>>>> Heiko, is it something that would make sense for the console based on this resource description: >>>>> >>>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1) >>>>> { >>>>> "outcome" => "success", >>>>> "result" => [ >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-colocated") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-master") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-slave") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "live-only") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-master") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "replication-slave") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> }, >>>>> { >>>>> "address" => [ >>>>> ("subsystem" => "messaging"), >>>>> ("hornetq-server" => "default"), >>>>> ("ha-policy" => "shared-store-colocated") >>>>> ], >>>>> "outcome" => "success", >>>>> "result" => { >>>>> ... >>>>> } >>>>> } >>>>> ] >>>>> } >>>>> >>>>> jeff >>>>> >>>>> -- >>>>> Jeff Mesnil >>>>> JBoss, a division of Red Hat >>>>> http://jmesnil.net/ >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Fri Oct 31 14:30:26 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 31 Oct 2014 19:30:26 +0100 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <5453C1D8.4080202@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> <5453C1D8.4080202@redhat.com> Message-ID: <70C6B73B-C9E3-470C-9465-44E0E662E2E2@redhat.com> On 31 Oct 2014, at 18:07, Brian Stansberry wrote: > This would definitely be useful. > > On the server side we already support a wildcard variant of > read-resource. But it only works within a single process, not across > processes in the domain. We've never had time to sort that issue. I'd > like to see this feature built on a foundation of a proper cross-domain > wildcard read-resource. That will kill two birds with one stone, plus > ensure consistent behavior. glad to hear. we specifically isolated it from the current codebase to explore the ideas, before merging with existing approaches. Bringing it into the main codebase would be a task for somebody with a better understanding of the management layer internals. > > Any other ideas for a name for this? "Map / reduce" to me implies a much > broader set of functionality, and I wouldn't want to falsely advertise, > nor burn an operation name that we may want later. the name describes quiet well what's actually happening behind the scenes, but I agree that "map/reduce" is quiet overloaded these days and might lead to false expectations. > That also relates to > Stan's point in his response, re: this being an element in a broader > query feature. If it has a precise name that implies a narrow scope, if > later on there is a broader feature that broader feature can co-exist > with its ancestor. > > On 10/31/14, 10:35 AM, Harald Pehl wrote: >> TL;DR >> >> For management clients it is tedious and awkward to read resources / >> attributes in big domains (e.g. return the state of all running servers >> across all hosts which are part of server group "foo"). Today this >> requires to setup multiple composite operations *on the client* which >> need to be executed in a specific order. This proposal suggests a new >> operation which collects all relevant information *on the >> server* and returns only the relevant data in one go to the client. >> >> -------------------- >> >> # Background: >> >> In the admin console we often need to read specific attributes across a >> domain or across a deeply nested resource: >> >> - List all enabled data sources of the current profile >> - Show the port offset of all running servers across all hosts >> - Get all users which belong to role Operator >> >> Even for small domains with two server groups and a small number of >> servers this procedure is awkward and error prone. What makes it even >> more difficult is the asynchronous nature of the admin console. Soon you >> end up in a deeply nested callback-hell. Besides that these 'queries' >> lead to poor performance for big domains with tens of groups, hosts and >> servers. >> >> # Proposal / Prototype >> >> The GitHub repository at [1] contains a more detailed description of the >> problem statement and a working prototype. This includes details such as >> how to address the requested resources, how the information is retrieved >> and how to handle errors. >> >> The proposal also includes a way to filter and reduce the resources >> against a list of attributes and values *before* the response is sent to >> the client. >> >> [1] https://github.com/hpehl/map-reduce >> >> --- >> 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 From hbraun at redhat.com Fri Oct 31 14:40:10 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 31 Oct 2014 19:40:10 +0100 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <5453B2CB.9050803@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> <5453B2CB.9050803@redhat.com> Message-ID: Haralds proposal was designed to be orthogonal to the concepts we currently have and embed within existing protocols and API. The idea is to build something straightforward to solve real problems. A query language sounds nice, but I don't really see how it relates to problems described in the former proposal. If you want to discuss that idea further, I would suggest to move it to another thread. On 31 Oct 2014, at 17:03, Stan Silvert wrote: > Taken to its logical conclusion, this would become a full-fledged query language. > > You could just create a client-side library for it and use that as the "language" develops. I think that would be a safe thing to do before committing it as part of the supported server side interface. > > How much of a problem would this be if it were not for GWT's callback-hell? It's my understanding that GWT is fixing that? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141031/578969a8/attachment.html From hbraun at redhat.com Fri Oct 31 14:46:21 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 31 Oct 2014 19:46:21 +0100 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> <5453B2CB.9050803@redhat.com> Message-ID: <3DB7D052-B6F9-4236-8F92-C82EAA3755F6@redhat.com> The problem has nothing todo with GWT. The single purpose of Haralds proposal is to reduce the number of requests and the actual amount of data when querying large groups of servers. The native interface suffer from this as well, it's just not that obvious because it's per se more performant then the HTTP interface (optimised wire format, persistent connections, etc). On 31 Oct 2014, at 17:05, Heiko W.Rupp wrote: > >> Am 31.10.2014 um 17:03 schrieb Stan Silvert : >> How much of a problem would this be if it were not for GWT's callback-hell? It's my understanding that GWT is fixing that? > > HAL is not the only client out there that needs that. > RHQ/JBoss ON can heavily benefit from that. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Fri Oct 31 15:05:11 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 31 Oct 2014 14:05:11 -0500 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <70C6B73B-C9E3-470C-9465-44E0E662E2E2@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> <5453C1D8.4080202@redhat.com> <70C6B73B-C9E3-470C-9465-44E0E662E2E2@redhat.com> Message-ID: <5453DD67.9040304@redhat.com> On 10/31/14, 1:30 PM, Heiko Braun wrote: > > On 31 Oct 2014, at 18:07, Brian Stansberry wrote: > >> This would definitely be useful. >> >> On the server side we already support a wildcard variant of >> read-resource. But it only works within a single process, not across >> processes in the domain. We've never had time to sort that issue. I'd >> like to see this feature built on a foundation of a proper cross-domain >> wildcard read-resource. That will kill two birds with one stone, plus >> ensure consistent behavior. > > glad to hear. we specifically isolated it from the current codebase to explore the ideas, before merging with existing approaches. Bringing it into the main codebase would be a task for somebody with a better understanding of the management layer internals. Oh. I can't commit to when we'd be able to do multi-process wildcard read-resource. I was fired up by the possibility that a talented guy like Harald was interested. :) This thread certainly raises the visibility of it though. I'll be thinking about how to do it. > >> >> Any other ideas for a name for this? "Map / reduce" to me implies a much >> broader set of functionality, and I wouldn't want to falsely advertise, >> nor burn an operation name that we may want later. > > the name describes quiet well what's actually happening behind the scenes, but I agree that "map/reduce" is quiet overloaded these days and might lead to false expectations. > >> That also relates to >> Stan's point in his response, re: this being an element in a broader >> query feature. If it has a precise name that implies a narrow scope, if >> later on there is a broader feature that broader feature can co-exist >> with its ancestor. >> >> On 10/31/14, 10:35 AM, Harald Pehl wrote: >>> TL;DR >>> >>> For management clients it is tedious and awkward to read resources / >>> attributes in big domains (e.g. return the state of all running servers >>> across all hosts which are part of server group "foo"). Today this >>> requires to setup multiple composite operations *on the client* which >>> need to be executed in a specific order. This proposal suggests a new >>> operation which collects all relevant information *on the >>> server* and returns only the relevant data in one go to the client. >>> >>> -------------------- >>> >>> # Background: >>> >>> In the admin console we often need to read specific attributes across a >>> domain or across a deeply nested resource: >>> >>> - List all enabled data sources of the current profile >>> - Show the port offset of all running servers across all hosts >>> - Get all users which belong to role Operator >>> >>> Even for small domains with two server groups and a small number of >>> servers this procedure is awkward and error prone. What makes it even >>> more difficult is the asynchronous nature of the admin console. Soon you >>> end up in a deeply nested callback-hell. Besides that these 'queries' >>> lead to poor performance for big domains with tens of groups, hosts and >>> servers. >>> >>> # Proposal / Prototype >>> >>> The GitHub repository at [1] contains a more detailed description of the >>> problem statement and a working prototype. This includes details such as >>> how to address the requested resources, how the information is retrieved >>> and how to handle errors. >>> >>> The proposal also includes a way to filter and reduce the resources >>> against a list of attributes and values *before* the response is sent to >>> the client. >>> >>> [1] https://github.com/hpehl/map-reduce >>> >>> --- >>> 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 ssilvert at redhat.com Fri Oct 31 15:16:50 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 31 Oct 2014 15:16:50 -0400 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> <5453B2CB.9050803@redhat.com> Message-ID: <5453E022.8030304@redhat.com> On 10/31/2014 2:40 PM, Heiko Braun wrote: > > Haralds proposal was designed to be orthogonal to the concepts we > currently have and embed within existing protocols and API. The idea > is to build something straightforward to solve real problems. > > A query language sounds nice, but I don't really see how it relates to > problems described in the former proposal. If you want to discuss that > idea further, I would suggest to move it to another thread. A lot of your particular problem is with GWT, and that is indeed a topic for another thread. Herald's proposal is a good one and people would want to do more with it than just solve your particular dilemma. Thus, it eventually becomes more and more like a query language. My point was just that if Herald is interested, he could easily do this on the client side and move it to the server side after it matures. But if Brian wants to plow ahead on the server side that's good too. > > On 31 Oct 2014, at 17:03, Stan Silvert > wrote: > >> Taken to its logical conclusion, this would become a full-fledged >> query language. >> >> You could just create a client-side library for it and use that as >> the "language" develops. I think that would be a safe thing to do >> before committing it as part of the supported server side interface. >> >> How much of a problem would this be if it were not for GWT's >> callback-hell? It's my understanding that GWT is fixing that? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141031/9c9696b4/attachment-0001.html From ssilvert at redhat.com Fri Oct 31 15:35:30 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 31 Oct 2014 15:35:30 -0400 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <3DB7D052-B6F9-4236-8F92-C82EAA3755F6@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> <5453B2CB.9050803@redhat.com> <3DB7D052-B6F9-4236-8F92-C82EAA3755F6@redhat.com> Message-ID: <5453E482.5070109@redhat.com> On 10/31/2014 2:46 PM, Heiko Braun wrote: > The problem has nothing todo with GWT. It has everything to do with GWT. The client code to deal with his problem is 10x simpler in real Java. I know because I've coded both many times. > > The single purpose of Haralds proposal is to reduce the number of requests and the actual amount of data when querying large groups of servers. The native interface suffer from this as well, it's just not that obvious because it's per se more performant then the HTTP interface (optimised wire format, persistent connections, etc). That's not true. Management requests are small, fast, and cheap. Doing it over HTTP makes no noticeable difference. The good thing about Harald's proposal is that it would make the code a little simpler for Java clients and a lot simpler for GWT clients. > > > On 31 Oct 2014, at 17:05, Heiko W.Rupp wrote: > >>> Am 31.10.2014 um 17:03 schrieb Stan Silvert : >>> How much of a problem would this be if it were not for GWT's callback-hell? It's my understanding that GWT is fixing that? >> HAL is not the only client out there that needs that. >> RHQ/JBoss ON can heavily benefit from that. >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From hpehl at redhat.com Fri Oct 31 17:33:20 2014 From: hpehl at redhat.com (Harald Pehl) Date: Fri, 31 Oct 2014 22:33:20 +0100 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <5453C1D8.4080202@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> <5453C1D8.4080202@redhat.com> Message-ID: > Am 31.10.2014 um 18:07 schrieb Brian Stansberry : > > Any other ideas for a name for this? "Map / reduce" to me implies a much > broader set of functionality, and I wouldn't want to falsely advertise, > nor burn an operation name that we may want later. I agree. The map / reduce name was kind of a working title. Any better terms are welcome! --- Harald Pehl JBoss by Red Hat http://hpehl.info From hpehl at redhat.com Fri Oct 31 18:18:33 2014 From: hpehl at redhat.com (Harald Pehl) Date: Fri, 31 Oct 2014 23:18:33 +0100 Subject: [wildfly-dev] Map / reduce for management operations In-Reply-To: <5453E482.5070109@redhat.com> References: <86CCB216-7726-4C75-9431-606DD4665CCF@redhat.com> <5453B2CB.9050803@redhat.com> <3DB7D052-B6F9-4236-8F92-C82EAA3755F6@redhat.com> <5453E482.5070109@redhat.com> Message-ID: <79DE39BE-0402-4C51-9FE4-2349AD9A95A7@redhat.com> > Am 31.10.2014 um 20:35 schrieb Stan Silvert : > > On 10/31/2014 2:46 PM, Heiko Braun wrote: >> The problem has nothing todo with GWT. > It has everything to do with GWT. The client code to deal with his > problem is 10x simpler in real Java. I know because I've coded both > many times. >> >> The single purpose of Haralds proposal is to reduce the number of requests and the actual amount of data when querying large groups of servers. The native interface suffer from this as well, it's just not that obvious because it's per se more performant then the HTTP interface (optimised wire format, persistent connections, etc). > That's not true. Management requests are small, fast, and cheap. Doing > it over HTTP makes no noticeable difference. > > The good thing about Harald's proposal is that it would make the code a > little simpler for Java clients and a lot simpler for GWT clients. It's really about making management operations for big domains easier and more performant. The current proposal is not meant to be a used as a query language. It's purpose is clearly focused to read resources / attributes over deeply nested or distributed resources. Whether the client is using GWT or any other language or framework is not the main focus of the proposal. It just happens to fit quite well to GWT's asynchronous nature. >> >> >> On 31 Oct 2014, at 17:05, Heiko W.Rupp wrote: >> >>>> Am 31.10.2014 um 17:03 schrieb Stan Silvert : >>>> How much of a problem would this be if it were not for GWT's callback-hell? It's my understanding that GWT is fixing that? >>> HAL is not the only client out there that needs that. >>> RHQ/JBoss ON can heavily benefit from that. >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev --- Harald Pehl JBoss by Red Hat http://hpehl.info