[jboss-as7-dev] AS7-431: unmanaged content

Heiko Braun hbraun at redhat.com
Mon May 2 07:51:38 EDT 2011 


well, in that case I think we are all in agreement and move forward right away.

On May 2, 2011, at 1:43 PM, Brian Stansberry wrote:

> 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 at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> jbossas-pull-requests mailing list
>>>>>>>>>>>> jbossas-pull-requests at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> jbossas-pull-requests mailing list
>>>>>>>>>>> jbossas-pull-requests at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> 
> 
> 
> -- 
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat

More information about the jboss-as7-dev mailing list