| Comment ID |
Date |
Section, Page Number/URL |
Comment |
Status – (RESOLVED/UNRESOLVED) |
| Example: jsmith-001 |
Date comment entered |
Detailed pointer to location in the doc |
Detailed comment |
Leave blank – the writer will provide status |
| tjquinn-001 |
25-Nov-2009 |
Gen'l Depl. Functionality, p. 36 |
The "Deployment Plan Deployment" bullet is accurate as written, but using deployment plans is an option open to users for any of the other five techniques listed in the other bullet points. It's orthogonal to those other five choices. Can we pull that out of the bullet list in a way that clarifies that it can apply to any of the deployment techniques? I'm not sure if that means the detailed description on p. 58 should be moved or amended. |
11/25/9 Edited and move the text to after the bullet list. I think p. 58 is OK as is. |
| tjquinn-002 |
25-Nov-2009 |
Deployment Descriptors and Annotations, p. 37 |
The first part of the second sentence should read "Each deployment descriptor XML file has a corresponding Document Type Definition (DTD) file or schema (XSD) file..." (The first bullet point does mention that the EE 6 spec uses schemas, but this early sentence should probably be generalized.) At the moment, the more recent EE versions use schemas but GlassFish continues to support all the older formats, the oldest of which are defined by DTDs. Also at the moment, the GlassFish-specific descriptors (sun-xxx.xml) are defined by DTDs although this could change at some point in the future. |
11/25/9 schema text added. If you want any of rest of this material added, I don't know where so did not do anything with it. |
| tjquinn-003 |
25-Nov-2009 |
p. 51, example 2-2 |
The example is a little confusing and I don't think it would actually be accepted. To match the description, the example should be
asadmin> deploy --retrieve . ejb.jar
(note the added dot). |
11/25/9 Done |
| tjquinn-004 |
25-Nov-2009 |
p. 58, Reviewer remark 2-1 |
Using deployment plans is indeed suitable for production or development use. See my earlier note. |
11/25/9 Done |
| tjquinn-005 |
25-Nov-2009 |
p. 59, "To Deploy ... Directory Format", second sentence |
It looks to me as if "archive" and "use" have run together. |
11/25/9 Done |
| tjquinn-006 |
25-Nov-2009 |
p. 59, Example 2-21 |
Maybe it's me, but I have no idea what it means that "The path name is accessed in the domain configuration file (domain.xml)." Does it mean that the path name is stored in the domain.xml file? If that's what it means, then that's accurate but that seems like an implementation detail that does not really help with the user's overall understanding of how to use directory deployment. |
I changed to "stored". Do you want anything else changed? |
| tjquinn-007 |
25-Nov-2009 |
p. 61, To Set a Web Context Parameter |
Are we being clear enough that by using the set-web-context-param command the user either (1) adds a new parameter that did not appear in the original web module's descriptor or (2) overrides the descriptor's setting of the parameter? (The same comment applies to the set-web-env-entry command.) Further, there's an additional aspect to these two set commands. If the user includes the --ignoreDescriptorItem=true option then the server will ignore any setting for that context param (or env entry) in the descriptor, and the user does not need to specify an overriding value on the set command. The server behaves as if the descriptor had never contained a setting for that context param (or env entry). |
Added material to both set- procedures. |
| tjquinn-008 |
25-Nov-2009 |
p. 70, item #5 |
Probably clearer to change "...retrieve the client JAR file" so it reads "...retrieve the client files" given the change in what we download in v3. Similar comment for the first bullet under #5: change it so it reads "use the deploy(1) subcommand with the --retrieve option to retrieve the client files as part of deploying the application." The second bullet might be clearer as: "Use the get-client-stubs(1) subcommand to retrieve the client files for a previously-deployed application." We should also emphasize that for a given application users need to use either but not both of "deploy --retrieve" and "get-client-stubs." |
11/25/9 Made these four changes. |
| tjquinn-009 |
25-Nov-2009 |
p. 70, item #6 |
I think this is redundant with #5. |
11/25/9 Deleted |
| tjquinn-010 |
25-Nov-2009 |
p. 70, item #7 |
This step is purely optional. The preceding steps are really necessary in order to run the client. |
11/25/9 Made the step Optional. |
| tjquinn-011 |
25-Nov-2009 |
p. 71, "Before You Begin" note |
This note implies that users can use either the appclient script or Java Web Start but not both. In fact users can use either or both. So the note should probably read "This task applies if you want to run the app client on a system other than where the server runs." All the system files needed by the appclient script are included in the server installation, so no extra prep is needed for that case. But to launch clients on other systems, the user needs to prepare that system as described. |
11/25/9 Done |
| bhaktimehta-001 |
25 nov 2009 |
Pg 73 |
Remark 2-3 Webservice Management is supported on admin console.In answer to your question since the doc only says about CLI maybe you can remove the whole paragraph on webservice management. Also am not sure if the publishing to registry is implemented and working so safer to remove that para |
This doc is only CLI. Can I remove the sentences about Admin GUI? If so, do we need to say more about the deploy command mentioned? 12/8/9 Hid the Web Service Mgmt bullet item. |
