Hi, Arun
Thanks for the comments! Let me try to answer some of the questions
and people from SERLI could add more:
> I reviewed the Versioning Document at:
>
> http://wiki.glassfish.java.net/Wiki.jsp?page=VersioningDesignDocument
>
> The document clearly explains how things work. Adding some more
> clarifications will make it more meaningful. Here are my comments
> based upon that:
>
> 1). I think the real benefits of versioning needs to be clearly
> defined. If only one version of an application is going to remain
> enabled at a given time, what use case does it serve ?
>
> Is it possible to keep another version of application available in
> non-production or test mode ? And then when enough testing has been
> done then roll it to production/enable mode ?
>
> 2). AIU rolling back and forward to a new version will save the
> precious deployment time. What is the differential between new
> deployment or switching to the old/new version ?
I agree with you that whartung has done a wonderful job explaining the
benefits, thanks whartung! We will try to capture the benefits better in
the document.
Eventually we want to provide runtime versioning where more than one
version of the application are enabled at the same time in the runtime,
so there will be no loss of service for users when they are upgrading or
rolling back the versions. This basic application versioning feature is
one step toward that direction.
>
> 3). The purpose of --name attribute is not clear, is it mandatory ?
It is mandatory if you want to use the versioning.
> Why can't it be derived from the archive name ? Do the deployable
> archive names need to be different ?
It's just more clear and has no ambiguity to use the name option. No,
the archive names do not need to be different.
> 4). Do the archive names need to be same if the redeployed version is
> same ?
No, the archive names are not really relevant here.
> 5). Some more details on how/where the internal versions are stored
> will be helpful.
How the versioned application is stored is really internal
implementation detail (which is subject to change). I am not sure if we
should expose this in the document.
> 6). 5.4 says "If the currently enabled version isn't matched by the
> expression, the command will result in a no-operation."
>
> I think the no-op will return an error message.
This is to be consistent with the current non versioned commands. If you
try to disable an already disabled application, or try to enable an
already enabled application, it will do nothing and tells you the
command executed successfully as what you want to achieve is achieved.
>
> 7). "asadmin disable foo:*" will disable the untagged version as well,
> right ? This will be in sync with "undeploy foo:*". If so, then this
> should be documented.
Yes, you are right. The document should be updated to make these two in
synch.
> 8). What is the use case of creating application ref ?
This is for clustering scenario. Say, you initially deploy all the
versions of the application to target X. And then target Y is created,
and you want some of these versions or all of these versions available
on target Y also, you would use create-application-ref command to
achieve that.
>
> 9). In 6, 2nd scenario, do deploying a new version automatically
> enable it as well ?
Depending on the value of the --enable attribute of the deploy command.
The default value of the --enable attribute is true.
>
> 10). In 8.2.1, should the error message be "Version foo:2 not
> registred" or "Version foo:2 not *deployed*" ? Ditto for 8.2.2.
Again, this is to be consistent with the existing error messages. If you
try to operate on a non-versioned application which does not exist, it
will also tell you that application is not registered yet.
Thanks,
- Hong
>
> On 5/19/10 1:45 PM, glassfish_at_javadesktop.org wrote:
>> 3.1 Deployment One Pager is now available for review here:
>>
>> http://wiki.glassfish.java.net/Wiki.jsp?page=3.1DeploymentOnePager
>>
>> The complete list of one-pagers for 3.1 is available here:
>>
>> http://wiki.glassfish.java.net/Wiki.jsp?page=V3FunctionalSpecs
>>
>> Comments are welcome. Thanks!
>> [Message sent by forum member 'hzhang_jn']
>>
>> http://forums.java.net/jive/thread.jspa?messageID=470560
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>