Re: [jboss-as7-dev] doamain deployments
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.
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.
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.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat