Hi Arun,
thanks for the comments, it's really useful for us.
I think whartung and Hong did a really great job with their answers, we just
want to add few things:
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 ?
We agree with and I think it's a good idea to include some use case in the
document to show the usefulness of application versioning. I think whartung
described really well the major benefits of basic versioning.
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 ?
The main difference is that the application is already deployed in the
application repository and when switching, the application has just to be
enabled.
The switch operation is done with the enable command which disables the old
version and enables the new one.
3). The purpose of --name attribute is not clear, is it mandatory ?
Why can't it be derived from the archive name ? Do the deployable archive
> names need to be different ?
Like Hong said, it's mandatory, because we want to be sure that the user
really wants to use versions for the app. It's called "explicit versioning"
in the document, when you use the versioning syntax in the --name option.
In my opinion it could be very ambigous derive versioned name from archive
name. If a user uses the versioning syntax in its archive names without
knowing it, the versioning system can be enable when the user doesn't want
it.
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.
In every cases, the "foo:*" syntax will match all the versions of "foo"
including the untagged one. We agree with you on this point, this should be
well documented in the document.
The disable command will always disable at most one version (only one
version can be enabled at a time).
We make this command as an expression aware operation to be more flexible
for users, so they don't have to remember the currently enabled version to
disable it.
Best regards.
Mathieu ANCELIN & Romain GRECOURT
SERLI
On Fri, May 21, 2010 at 4:22 AM, Hong Zhang <hong.hz.zhang_at_oracle.com>wrote:
> 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
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
--
Cordialement.
Mathieu ANCELIN