[wildfly-dev] Confusion around deployment runtime-name

Brian Stansberry brian.stansberry at redhat.com
Fri Jun 14 11:48:21 EDT 2013


On 6/13/13 2:48 PM, Jason Greene wrote:
>
> On Jun 13, 2013, at 9:12 AM, Bartosz Baranowski <bbaranow at redhat.com> wrote:
>
>> Hi guys.
>>
>> Im trying to fix one of EAPs BZ and this led me into deep state of confusion.
>> Said BZ: https://bugzilla.redhat.com/show_bug.cgi?id=964446
>>
>>
>> Ive looked into CLI and this is what it offers:
>>
>>
>> [standalone at localhost:9990 /] deploy --help
>> SYNOPSIS
>>
>>     deploy ((file_path | --url=deployment_url)
>>                [--script=script_name] [--name=deployment_name]
>>                [--runtime-name=deployment_runtime_name]
>>               ...
>>
>>
>> file_path         - filesystem path to the application to deploy.
>>                      If the deployment has to be added or replaced in the
>>                      repository, either the file_path or the --url argument
>>                      is required.
>>                      The path can be either absolute or relative to the current
>>                      directory.
>>
>> --url             - ...
>>
>> --name            - the unique name of the deployment. If the file path
>>                      argument is specified the name argument is optional with
>>                      the file name been the default value. If the file path
>>                      argument isn't specified then the command is supposed to
>>                      enable an already existing but disabled deployment, and in
>>                      this case the name argument is required.
>>
>> --runtime-name    - optional, the runtime name for the deployment.
>>
>>
>>
>> A bit vague description of --runtime-name.

Agreed.

https://github.com/wildfly/wildfly/pull/4646

Thanks.

--name gives a bit more info - it tells me that ${name} will be part of 
PathAddress in AS7 model.
>> I kept digging and found this bit in DMR file:
>>
>> Name by which the deployment should be known within a server's runtime. This would be equivalent to the file name of a deployment file, and would form the basis for such things as default Java Enterprise Edition application and module names. This would typically be the same as 'name', but in some cases users may wish to have two deployments with the same 'runtime-name' (e.g. two versions of \"foo.war\") both available in the deployment content repository, in which case the deployments would need to have distinct 'name' values but would have the same 'runtime-name'."
>>
>>
>> Ok now to the point:
>> 1. ${runtime-name} is used as 'root' of deployment. It becomes a part of service name in jboss MSC. However model name contains ${name}/archive name as root of PathAddress.
>>
>> Is this correct? I've been told that this is wrong and the ${runtime-name} should be also part of PathAddress.

That was incorrect information. A PathAddress is used for addressing 
management resources. The ${name} is the correct value for management 
resources.

>> #1 is essentially a root of BZ. Operation seek service which contain ${name} as part of service name, while MSC has service which has the ${runtime-name}:
>> lookup value:        jboss.deployment.subunit."jboss-as-ejb-in-ear-ear.ear"."jboss-as-ejb-in-ear-ejb.jar".component.GreeterEJB.START
>> actual msc service:  jboss.deployment.subunit."nnn.ear"."jboss-as-ejb-in-ear-ejb.jar".component.GreeterEJB.START
>>

The lookup is incorrect.

>>
>> 2. From above description of runtime-name it seems I should be able to execute:
>> deploy --runtime-name=nnn.ear /x/archive-1.0.ear
>> deploy --runtime-name=nnn.ear /x/archive-1.1.ear
>>
>> In fact I'm able to do that, but I've been told that this is wrong. Which is it?
>

You should be able to do this.

>
> You can only have one of a runtime name in a server instance (JVM). However, you might have two different server groups, which both have an account-manager.ear, but both are completely different. Both might also rely on that name (e.g. global JNDI names are created based on the deployment name). All servers share the same content repository, so to handle that situation they need different names to establish uniqueness in the repository, but identical runtime-names to allow them to execute correctly.
>

Even in a standalone server configuration you can have two deployments 
with different names but the same runtime name. You just can't have them 
both *deployed* at the same time. But the management model allows you to 
have two deployment resources with different names but the same 
runtime-name, so long as one is *disabled*.

> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list