Skip to main content

3.1 Deployment One Pager : Clustering Deployment, Application Versioning

9 replies [Last post]
hzhang_jn
Offline
Joined: 2005-07-22
Points: 0

3.1 Deployment One Pager is now available for review here:

http://wiki.glassfish.java.net/Wiki.jsp?page=3.1DeploymentOnePager

The focus of this release will be providing v2 feature partity for clustering deployment. Also there is new feature of application versioning!

The complete list of one-pagers for 3.1 is available here:

http://wiki.glassfish.java.net/Wiki.jsp?page=V3FunctionalSpecs

Please let us know your comments by May 27th. Thanks!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Arun Gupta

Hi Hong,

See in line ...

>> 3). The purpose of --name attribute is not clear, is it mandatory ?
> It is mandatory if you want to use the versioning.
I think this needs to be clearly documented in that case.

>> 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.
Agreed, unique name will make the archive name redundant.

>> 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.
Agreed, I guess some internal document might be helpful for folks like
me :-)

>> 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.
This is a different use case though.

The text indicates that no version is matched by the specified
expression so there is nothing to enable and hence the request was not
met successfully. Am I understanding it incorrectly ?

>>
>> 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.
OK, makes sense as this was not mentioned in the doc.

>>
>> 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.
What is the difference between "registered" and "deployed" ?

-Arun

--
Blog: http://blogs.sun.com/arungupta
Twitter: http://twitter.com/arungupta

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Hong Zhang

Hi, Arun
>>> 3). The purpose of --name attribute is not clear, is it mandatory ?
>> It is mandatory if you want to use the versioning.
> I think this needs to be clearly documented in that case.
Yeah, make sense.
>>> 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.
> Agreed, I guess some internal document might be helpful for folks like
> me :-)
Yes, we probably could have another document talking about some of the
implementation details for people who are interested (but not exposed to
end users).
>>> 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.
> This is a different use case though.
>
> The text indicates that no version is matched by the specified
> expression so there is nothing to enable and hence the request was not
> met successfully. Am I understanding it incorrectly ?
Section 5.4 is for disable command? If there is nothing to disable,
means all the versions are already disabled?
>>>
>>> 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.
> OK, makes sense as this was not mentioned in the doc.
Ok, probably in section 5.1 when it talks about deploy command, it could
mention this so users are clear about it.
>>>
>>> 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.
> What is the difference between "registered" and "deployed" ?
No real difference. Somehow the previous releases chose to use word
"registered" and we just followed it.

Thanks,

- Hong

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Hong Zhang

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@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@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Mathieu ANCELIN

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 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@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@glassfish.dev.java.net
>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

--

Cordialement.

Mathieu ANCELIN
[att1.html]

Arun Gupta

Now also available at:

http://wiki.glassfish.java.net/Wiki.jsp?page=VersioningArunGupta

Thanks,
-Arun

On 5/20/10 9:56 AM, Arun Gupta wrote:
> 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 ?
>
> 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 ?
>
> 4). Do the archive names need to be same if the redeployed version is
> same ?
>
> 5). Some more details on how/where the internal versions are stored will
> be helpful.
>
> 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.
>
> 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.
>
> 8). What is the use case of creating application ref ?
>
> 9). In 6, 2nd scenario, do deploying a new version automatically enable
> it as well ?
>
> 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.
>
> Thanks,
> -Arun
>
> On 5/19/10 1:45 PM, glassfish@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@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>

--
Blog: http://blogs.sun.com/arungupta
Twitter: http://twitter.com/arungupta

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

hzhang_jn
Offline
Joined: 2005-07-22
Points: 0

The review for this one-pager is now closed. Thanks for your comments and feedback!

Feel free to add any additional comments but we might not be able to incorporate them in this release.

Arun Gupta

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 ?

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 ?

4). Do the archive names need to be same if the redeployed version is same ?

5). Some more details on how/where the internal versions are stored will
be helpful.

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.

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.

8). What is the use case of creating application ref ?

9). In 6, 2nd scenario, do deploying a new version automatically enable
it as well ?

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.

Thanks,
-Arun

On 5/19/10 1:45 PM, glassfish@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@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

--
Blog: http://blogs.sun.com/arungupta
Twitter: http://twitter.com/arungupta

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

whartung
Offline
Joined: 2003-06-13
Points: 0

Not having written the spec, the primary benefit of multiple versions is simply the ability to switch versions quickly.

If you go through a typical use case right now, deployment consists of copying files and updating domain.xml.

An example is say you have an application on a remote server. If you use the GUI or a remote CLI, deploying a new copy of running application consists:

1) Downing the current application

2) Undeploying the current application

3) Copying up the new aritifact (EAR/WAR).

4) Expanding that artifact on the app server.

5) Deploying the new application.

6) Starting the new application.

You can see that if you have a particularly slow connection, or a large application, the downtime of the existing application can be significant.

One way to avoid this is to copy and expand your application to the app server first, then undeploy the old app and deploy the new app from a directory.

But if something goes wrong, the old app is undeployed and your application server doesn't have a running version of the app. So to "roll back" you would have to redeploy the old copy.

if you copy the new application to "newdir" while leaving the old application in "olddir", this rollback isn't necessarily very difficult.

However, if you simply deployed your new app "over" the old one, the old app isn't there at all any more, so there is no quick rollback. You'd have to upload and deploy the old version.

By letting you "stage" different versions of the application, you can help minimize application downtime during upgrades. As I mentioned, you can do this "by hand" right now, but if you wanted to deploy an application to a cluster of machines, that's a lot of hoop jumping and coordination.

With versioned applications, the app server can do this for you, and, ideally, let you switch over (and back) very quickly with little management on your part.

As for being able to run 2 versions simultaneously, that seems like quite a hurdle above what basic versioning can offer. You would have to be able to set up an alternate listener, to deploy the other version on different ports. But you would also have to be very careful about application design, resource sharing (both apps using the same connection pool for example), etc.

I can see a lot of value with the basic versioning in terms of administration (assuming I'm understanding what it is supposed to do correctly).

Arun Gupta

Thanks for the wonderful explanation, that's exactly how I understood as
well.

All I'm trying to say is that it might be worthwhile to capture the
benefits in a formal document :-)

-Arun

On 5/20/10 10:37 AM, glassfish@javadesktop.org wrote:
> Not having written the spec, the primary benefit of multiple versions is simply the ability to switch versions quickly.
>
> If you go through a typical use case right now, deployment consists of copying files and updating domain.xml.
>
> An example is say you have an application on a remote server. If you use the GUI or a remote CLI, deploying a new copy of running application consists:
>
> 1) Downing the current application
>
> 2) Undeploying the current application
>
> 3) Copying up the new aritifact (EAR/WAR).
>
> 4) Expanding that artifact on the app server.
>
> 5) Deploying the new application.
>
> 6) Starting the new application.
>
> You can see that if you have a particularly slow connection, or a large application, the downtime of the existing application can be significant.
>
> One way to avoid this is to copy and expand your application to the app server first, then undeploy the old app and deploy the new app from a directory.
>
> But if something goes wrong, the old app is undeployed and your application server doesn't have a running version of the app. So to "roll back" you would have to redeploy the old copy.
>
> if you copy the new application to "newdir" while leaving the old application in "olddir", this rollback isn't necessarily very difficult.
>
> However, if you simply deployed your new app "over" the old one, the old app isn't there at all any more, so there is no quick rollback. You'd have to upload and deploy the old version.
>
> By letting you "stage" different versions of the application, you can help minimize application downtime during upgrades. As I mentioned, you can do this "by hand" right now, but if you wanted to deploy an application to a cluster of machines, that's a lot of hoop jumping and coordination.
>
> With versioned applications, the app server can do this for you, and, ideally, let you switch over (and back) very quickly with little management on your part.
>
> As for being able to run 2 versions simultaneously, that seems like quite a hurdle above what basic versioning can offer. You would have to be able to set up an alternate listener, to deploy the other version on different ports. But you would also have to be very careful about application design, resource sharing (both apps using the same connection pool for example), etc.
>
> I can see a lot of value with the basic versioning in terms of administration (assuming I'm understanding what it is supposed to do correctly).
> [Message sent by forum member 'whartung']
>
> http://forums.java.net/jive/thread.jspa?messageID=470745
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

--
Blog: http://blogs.sun.com/arungupta
Twitter: http://twitter.com/arungupta

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net