On Fri, Apr 29, 2011 at 12:48 PM, Brian Stansberry wrote: ... > "hash" -- the sha1 hash for managed content > OR, if "hash" is undefined, meaning content is unmanaged" > "archive" -- ModelType.BOOLEAN indicating whether the unmanaged content > is a zip > "path" -- absolute or relative filesystem path > "relative-to" -- (optional if "path is absolute) name of a system path > against which "path" should be resolved And "root" to control the context-relative path for FS resources? I personally like "context-relative-path" better than "root"... =)p

Switching to the main as7 dev list as when this is ready it's going to require some coordination. But first some comments on the patch: 1) Looks like there's a problem with the "relativeTo" handling in FileSystemDeploymentScannerService: http://pastebin.com/3PhN3VLg 2) DeploymentFullReplaceHandler in domain-controller needs conversion as well. 3) ServerDeploymentRepository.addExternalFileReference can disappear. :) Now the coordination part: This work will break the existing console and the CLI, so before merging it we'll need a coordinated change to those (cli is easier since it's the same code base). The change this introduces can be conceptualized by looking at the xml in the JIRA description at [1] a) the content of a deployment is now represented via a child element, instead of just the attribute on the <deployment/> element. b) we support "unmanaged" content, where the child element points to an archive or exploded directory on the filesystem. Unmanaged means we haven't slurped the deployment bits into our content repository from which we will deploy them (and replicate them around the domain if domain mode is used.) Instead it's the user's responsibility to put the files where they say they are. c) the eventual aim is to support associating multiple pieces of content with a deployment, although this is not currently implemented. Effect of this is in the configuration model on Carlo's branch, a resource representing a deployment no longer has a "hash" attribute. Instead it has a "content" attribute of type ModelType.LIST. Each element in that list has these attributes: "hash" -- the sha1 hash for managed content OR, if "hash" is undefined, meaning content is unmanaged" "archive" -- ModelType.BOOLEAN indicating whether the unmanaged content is a zip "path" -- absolute or relative filesystem path "relative-to" -- (optional if "path is absolute) name of a system path against which "path" should be resolved The "add" and "full-replace" operations for a deployment have analogous changes. Instead of root level parameters describing the content (e.g. "hash" or "input-stream-index" or "url") they take a root level "content" parameter of ModelType.LIST. The elements in the list describe the content. We need to decide what to do with the <deployment> element under <server-group>. I don't see any reason to duplicate all the content stuff. Simpler is just listing the unique name and whether the deployment is enabled: <domain> <deployments> <deployment name="foo.ear" runtime-name="foo.ear"> <content id="d37ede977b022a1456ec5e7a5eee07549cb1c414"/> </deployment> </deployments> <server-groups> <server-group ...> <deployments> <deployment name="foo.ear" enabled="true"/> </deployments> </server-group> </server-groups> </domain> [1] https://issues.jboss.org/browse/AS7-431 On 4/28/11 10:16 PM, Brian Stansberry wrote: > My system has been screwed up all afternoon/evening. I'm going to have > to look at this in the morning. :( > > On 4/28/11 3:31 PM, Carlo de Wolf wrote: >> Test is passing now. >> >> https://github.com/jbossas/jboss-as/pull/32 is amended. >> >> Carlo >> >> On 04/27/2011 06:28 AM, Brian Stansberry wrote: >>> On 4/26/11 5:07 PM, Brian Stansberry wrote: >>>> I tested the former using the domain.interactive demo. That's not >>>> adequate of course. We need to solve knowing when a HostController and >>>> all its servers are fully up so we can execute proper tests without >>>> getting spurious failures due to timing. >>>> >>>> For the exploded thing, I'll add a variant of >>>> ServerInModuleStartupTestCase.testFilesystemDeployment(), hopefully >>>> tonight. >>>> >>> >>> Test added to upstream: >>> http://github.com/jbossas/jboss-as/compare/54d4c17...b8eb339 >>> >>>> On 4/26/11 4:24 PM, Carlo de Wolf wrote: >>>>> Do we have test cases for those things? >>>>> >>>>> Carlo >>>>> >>>>> On 04/26/2011 10:58 PM, Brian Stansberry wrote: >>>>>> See https://github.com/bstansberry/jboss-as/commits/AS7-431 for the >>>>>> small things. >>>>>> >>>>>> Before we can merge this though, we need: >>>>>> >>>>>> 1) the DeploymentFullReplaceHandlers to work >>>>>> 2) exploded deployment from the deployments/ dir is broken. We should >>>>>> convert the FS scanner to add unmanaged content. >>>>>> >>>>>> If it's not implemented before this is merged, we need to have a JIRA >>>>>> for the TODO in domain mode DeploymentAddHandler to deal with >>>>>> unmanaged >>>>>> content. >>>>>> >>>>>> On 4/26/11 1:46 PM, Brian Stansberry wrote: >>>>>>> I'm testing this out; have a few comments, but I think the easiest >>>>>>> way >>>>>>> to make them is to put them on a branch. >>>>>>> >>>>>>> One thing to discuss is the name of this "content" dir. I don't much >>>>>>> like that name since 1) it's so vague 2) we use the same name in >>>>>>> other >>>>>>> places in the dist for the dir where we store managed content. The >>>>>>> old >>>>>>> "system-content" in Alpha1 somewhat indicated that it was our >>>>>>> stuff, not >>>>>>> theirs. If we're not concerned about that "ours vs. theirs" >>>>>>> distinction >>>>>>> and are just trying to create a well-known location for sticking >>>>>>> unmanaged content, then perhaps "unmanaged-content" ? (I hope someone >>>>>>> has a better suggestion.) >>>>>>> >>>>>>> On 4/26/11 10:21 AM, Carlo de Wolf wrote: >>>>>>>> Now with domain working. >>>>>>>> >>>>>>>> Carlo >>>>>>>> >>>>>>>> On 04/26/2011 01:53 PM, Carlo de Wolf wrote: >>>>>>>>> As Kabir spotted, the domain-controller bits are not working. I'm >>>>>>>>> working on those now. >>>>>>>>> >>>>>>>>> Carlo >>>>>>>>> >>>>>>>>> On 04/26/2011 10:15 AM, Carlo de Wolf wrote: >>>>>>>>>> Please review or pull https://github.com/jbossas/jboss-as/pull/32. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Carlo >>>>>>>>>> _______________________________________________ >>>>>>>>>> jbossas-pull-requests mailing list >>>>>>>>>> jbossas-pull-requests(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests >>>>>>>>> _______________________________________________ >>>>>>>>> jbossas-pull-requests mailing list >>>>>>>>> jbossas-pull-requests(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests >>>>>>>> _______________________________________________ >>>>>>>> jbossas-pull-requests mailing list >>>>>>>> jbossas-pull-requests(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> > > -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Jason decided not to do Beta4, so there's no other formal release planned before the CR. On 5/2/11 7:32 AM, Heiko Braun wrote: > > We (AS7 Console) already finished out current iteration > and expect the next AS7 release to retain the existing deployment API. > > But after that, we start migrating to the next deployment API version: > https://issues.jboss.org/browse/AS7-448 > > So if you don't mind, I would suggest we wrap up the next AS release > and once that is done begin the migration to the new API. > > Regards, Heiko > > On Apr 29, 2011, at 8:48 PM, Brian Stansberry wrote: > >> Switching to the main as7 dev list as when this is ready it's going to >> require some coordination. But first some comments on the patch: >> >> 1) Looks like there's a problem with the "relativeTo" handling in >> FileSystemDeploymentScannerService: >> >> http://pastebin.com/3PhN3VLg >> >> 2) DeploymentFullReplaceHandler in domain-controller needs conversion as >> well. >> >> 3) ServerDeploymentRepository.addExternalFileReference can disappear. :) >> >> Now the coordination part: >> >> This work will break the existing console and the CLI, so before merging >> it we'll need a coordinated change to those (cli is easier since it's >> the same code base). >> >> The change this introduces can be conceptualized by looking at the xml >> in the JIRA description at [1] >> >> a) the content of a deployment is now represented via a child element, >> instead of just the attribute on the<deployment/> element. >> b) we support "unmanaged" content, where the child element points to an >> archive or exploded directory on the filesystem. Unmanaged means we >> haven't slurped the deployment bits into our content repository from >> which we will deploy them (and replicate them around the domain if >> domain mode is used.) Instead it's the user's responsibility to put the >> files where they say they are. >> c) the eventual aim is to support associating multiple pieces of content >> with a deployment, although this is not currently implemented. >> >> Effect of this is in the configuration model on Carlo's branch, a >> resource representing a deployment no longer has a "hash" attribute. >> Instead it has a "content" attribute of type ModelType.LIST. Each >> element in that list has these attributes: >> >> "hash" -- the sha1 hash for managed content >> OR, if "hash" is undefined, meaning content is unmanaged" >> "archive" -- ModelType.BOOLEAN indicating whether the unmanaged content >> is a zip >> "path" -- absolute or relative filesystem path >> "relative-to" -- (optional if "path is absolute) name of a system path >> against which "path" should be resolved >> >> The "add" and "full-replace" operations for a deployment have analogous >> changes. Instead of root level parameters describing the content (e.g. >> "hash" or "input-stream-index" or "url") they take a root level >> "content" parameter of ModelType.LIST. The elements in the list describe >> the content. >> >> We need to decide what to do with the<deployment> element under >> <server-group>. I don't see any reason to duplicate all the content >> stuff. Simpler is just listing the unique name and whether the >> deployment is enabled: >> >> <domain> >> <deployments> >> <deployment name="foo.ear" runtime-name="foo.ear"> >> <content id="d37ede977b022a1456ec5e7a5eee07549cb1c414"/> >> </deployment> >> </deployments> >> >> <server-groups> >> <server-group ...> >> <deployments> >> <deployment name="foo.ear" enabled="true"/> >> </deployments> >> </server-group> >> </server-groups> >> </domain> >> >> [1] https://issues.jboss.org/browse/AS7-431 >> >> On 4/28/11 10:16 PM, Brian Stansberry wrote: >>> My system has been screwed up all afternoon/evening. I'm going to have >>> to look at this in the morning. :( >>> >>> On 4/28/11 3:31 PM, Carlo de Wolf wrote: >>>> Test is passing now. >>>> >>>> https://github.com/jbossas/jboss-as/pull/32 is amended. >>>> >>>> Carlo >>>> >>>> On 04/27/2011 06:28 AM, Brian Stansberry wrote: >>>>> On 4/26/11 5:07 PM, Brian Stansberry wrote: >>>>>> I tested the former using the domain.interactive demo. That's not >>>>>> adequate of course. We need to solve knowing when a HostController and >>>>>> all its servers are fully up so we can execute proper tests without >>>>>> getting spurious failures due to timing. >>>>>> >>>>>> For the exploded thing, I'll add a variant of >>>>>> ServerInModuleStartupTestCase.testFilesystemDeployment(), hopefully >>>>>> tonight. >>>>>> >>>>> >>>>> Test added to upstream: >>>>> http://github.com/jbossas/jboss-as/compare/54d4c17...b8eb339 >>>>> >>>>>> On 4/26/11 4:24 PM, Carlo de Wolf wrote: >>>>>>> Do we have test cases for those things? >>>>>>> >>>>>>> Carlo >>>>>>> >>>>>>> On 04/26/2011 10:58 PM, Brian Stansberry wrote: >>>>>>>> See https://github.com/bstansberry/jboss-as/commits/AS7-431 for the >>>>>>>> small things. >>>>>>>> >>>>>>>> Before we can merge this though, we need: >>>>>>>> >>>>>>>> 1) the DeploymentFullReplaceHandlers to work >>>>>>>> 2) exploded deployment from the deployments/ dir is broken. We should >>>>>>>> convert the FS scanner to add unmanaged content. >>>>>>>> >>>>>>>> If it's not implemented before this is merged, we need to have a JIRA >>>>>>>> for the TODO in domain mode DeploymentAddHandler to deal with >>>>>>>> unmanaged >>>>>>>> content. >>>>>>>> >>>>>>>> On 4/26/11 1:46 PM, Brian Stansberry wrote: >>>>>>>>> I'm testing this out; have a few comments, but I think the easiest >>>>>>>>> way >>>>>>>>> to make them is to put them on a branch. >>>>>>>>> >>>>>>>>> One thing to discuss is the name of this "content" dir. I don't much >>>>>>>>> like that name since 1) it's so vague 2) we use the same name in >>>>>>>>> other >>>>>>>>> places in the dist for the dir where we store managed content. The >>>>>>>>> old >>>>>>>>> "system-content" in Alpha1 somewhat indicated that it was our >>>>>>>>> stuff, not >>>>>>>>> theirs. If we're not concerned about that "ours vs. theirs" >>>>>>>>> distinction >>>>>>>>> and are just trying to create a well-known location for sticking >>>>>>>>> unmanaged content, then perhaps "unmanaged-content" ? (I hope someone >>>>>>>>> has a better suggestion.) >>>>>>>>> >>>>>>>>> On 4/26/11 10:21 AM, Carlo de Wolf wrote: >>>>>>>>>> Now with domain working. >>>>>>>>>> >>>>>>>>>> Carlo >>>>>>>>>> >>>>>>>>>> On 04/26/2011 01:53 PM, Carlo de Wolf wrote: >>>>>>>>>>> As Kabir spotted, the domain-controller bits are not working. I'm >>>>>>>>>>> working on those now. >>>>>>>>>>> >>>>>>>>>>> Carlo >>>>>>>>>>> >>>>>>>>>>> On 04/26/2011 10:15 AM, Carlo de Wolf wrote: >>>>>>>>>>>> Please review or pull https://github.com/jbossas/jboss-as/pull/32. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Carlo >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> jbossas-pull-requests mailing list >>>>>>>>>>>> jbossas-pull-requests(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jbossas-pull-requests mailing list >>>>>>>>>>> jbossas-pull-requests(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests >>>>>>>>>> _______________________________________________ >>>>>>>>>> jbossas-pull-requests mailing list >>>>>>>>>> jbossas-pull-requests(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> -- >> Brian Stansberry >> Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > -- Brian Stansberry Principal Software Engineer JBoss by Red Hat