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

Brian Stansberry brian.stansberry at redhat.com
Mon May 2 07:43:55 EDT 2011 

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