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

Brian Stansberry brian.stansberry at redhat.com
Fri Apr 29 14:48:06 EDT 2011 

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

More information about the jboss-as7-dev mailing list