1:48 p.m.
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