2:07 p.m.
On 02/18/2011 01:46 PM, Brian Stansberry wrote:
On 2/18/11 12:34 PM, David M. Lloyd wrote:
> On 02/18/2011 12:29 PM, Brian Stansberry wrote:
>> On 2/18/11 11:02 AM, Heiko Braun wrote:
>>>
>>> +1
>>>
>>> I was thinking along the same lines.
>>> A domain deployment either disabled or not. But If it's enabled,
>>> it still needs to be referenced from a server group. Otherwise it just sits
>>> in the domain controller repo.
>>>
>>> IMO, the "disabled" attribute would be sufficient.
>>> But what happens when a previously enabled and referenced deployment
(deployed to host)
>>> is disabled?
>>
>> I was thinking the "disabled" flag would not exist in domain.xml on:
>>
>> <domain>
>> <deployments>
>> <deployments name="xxx" runtime-name="xxx"
sha1="asfs"/>
>> </deployments>
>> </domain>
>>
>> That element simply records what's available in the central deployment repo.
>
> Indeed. My research is indicating that this may not even make sense to
> do any more - we don't get any value from it other than validation. And
> there will come a time in the near future when content items do not
> correspond to deployments on a 1:1 basis; so this will merely be a
> declaration of what's in the content repository.
>
> I'm starting to think that this information (domain-level deployment
> element data) is completely superfluous.
It's also the authoritative mapping between the name and the hash. (If
it becomes 1:n then it would become a mapping between name and hashes).
Besides being for validation, it allows the user to access the mapping
info, e.g. if they add some content today and then want to actually push
it to server groups tomorrow. A bit contrived, I admit.
Yeah in the future there probably won't be a (technical) need for such a
mapping because the hash will be associated purely with content and not
a deployment, so you'd be able to have:
<deployment name="foo.war">
<content id="000001"/>
<content id="000002"/>
</deployment>
<deployment name="bar.war">
<content id="000001"/>
<content id="000003"/>
</deployment>
or even mixed content specs like this:
<deployment name="foo.war">
<content id="000001"/>
<filesystem-content relative-to="jboss.deploy.dir"
name="my-content.jar"/>
</deployment>
If we drop the notion of attaching names to content then this is the end
of it. If not then it probably makes more sense to have <content>
declarations in the domain (and standalone) config where names are stuck
on to different content bits. But at this point it's not clear what the
benefit would be (well, except for the possibly major benefit that we
would not be forcing the users to pick a domain-wide unique name for
every blob that they deploy into a domain).
I'd love to make the whole hash thing go away, or at least make
it
invisible to the end user. Right now there's a few things driving the
need for the hash:
1) The process of adding content in the past involved two steps (which
the deployment manager convenience API hid from users):
uploading/storing content and then assigning a name to the content. The
hash got returned to the client after the first, and then passed back to
the server when the user assigned the name.
Yeah I guess this wouldn't change much, at least superficially.
When we implement the idea of being able to associate streams with
an
operation request, that will eliminate the need for doing things in 2 steps.
2) If you do a "full replace" operation, where you have version 2 of
foo.war replacing version 1, the two distinct hashes are used to
discriminate the two sets of content as the operation is carried out.
3) The hashes are useful in ensuring that a host's copy of
content is
consistent with the central repo.
I'll think a bit about whether how 2) and 3) work can be changed such
that the hashes are purely internal details that don't need to be
exposed to the end user.
Yeah that'll be tricky.
--
- DML