[GLASSFISH-19169] need REST API for _load-default-log-attributes and _load-default-log-levels Created: 17/Oct/12  Updated: 29/Jan/13  Resolved: 29/Jan/13

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: None
Fix Version/s: 4.0_b59

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16018 AdminConsole: Logger Settings page is... Reopened

 Description   

The 2 commands is available

Commands are _load-default-log-attributes and _load-default-log-levels.

but no REST resource for them.
GF console needs the REST resource to support the default button requested in GLASSFISH-16018



 Comments   
Comment by Jason Lee [ 29/Jan/13 ]

Fix committed (r58911)





[GLASSFISH-19110] javax.json.* package not referenced from MANIFEST file in javaee.jar Created: 27/Sep/12  Updated: 10/Oct/12  Resolved: 10/Oct/12

Status: Resolved
Project: glassfish
Component/s: other
Affects Version/s: 4.0_b57
Fix Version/s: 4.0_b59

Type: Bug Priority: Major
Reporter: Ryan O'Connell Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Looking at the GF V4 nightly from September 27th, it looks like the MANIFEST in javaee.jar does not contain a reference to the javax.json.jar. So user application importing javax.json building against javaee.jar will fail to compile. I checked the 25th build as well and javax.json.jar is not referenced there so it was probably never added to the MANIFEST.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 10/Oct/12 ]

Fix committed. Promoted build 58 seems to be in progress, so setting target fix version to 4.0_b59.





[GLASSFISH-18869] deploy --type does not accept valid archive types Created: 07/Jul/12  Updated: 26/Oct/12  Resolved: 24/Oct/12

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: None
Fix Version/s: 4.0_b59

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File Jar.ear     Zip Archive singleton-osgi.zip     File test_sample1.war    

 Description   

I would expect --type option in deployment to accept all valid archive types supported in a runtime. That's not the case; it only accepts osgi for some reason. See the error below:

ss141213@Sahoo:/tmp$ asadmin deploy --type war ~/bugs/FirstV3Test/dist/FirstV3Test.war
remote failure: Error occurred during deployment: There is no installed container capable of handling this application FirstV3Test. Please see server.log for more details.
Command deploy failed.



 Comments   
Comment by Hong Zhang [ 09/Jul/12 ]

This is the expected behavior, currently the supported value of the type option is only "osgi", I think we discussed before about the history/reasoning behind this , we could possibly enhance the type option to support more archive types.

Comment by Sanjeeb Sahoo [ 09/Jul/12 ]

For the sake of completeness, we should support --type=<any supported archive type in current runtime>. I don't mind you making it an improvement or bug as long as it is done and not lost in the stack somewhere.

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.

Comment by Jeremy_Lv [ 24/Oct/12 ]

Hong:
Have anyone fixed this scenario already? Nowadays, I can deploy with --type option successfully. The commands are as follows:
1.asadmin deploy --type war test_sample1.war
2.asadmin deploy --type ejb singleton-osgi-1.0.jar
3.asadmin deploy --type osgi singleton-osgi-1.0.jar
4.asadmin deploy --type ear Jar.ear


I will attached my test applications to JIRA later

Comment by Jeremy_Lv [ 24/Oct/12 ]

related applications have been attached

Comment by Jeremy_Lv [ 24/Oct/12 ]

Environment to test
version:GFv4(update by 2012/10/24)
Platform:Win 7
JDK:jdk1.7.0_04

Comment by Hong Zhang [ 24/Oct/12 ]

Yes, I have made some changes in this area when I was working on another issue. But I haven't got a chance to verify if that set of the changes were all the changes needed to address this requirement. Thanks for verifying this for me. I will go ahead and mark the issue as fixed.

Comment by Sanjeeb Sahoo [ 24/Oct/12 ]

We should update the help text for deploy to mention about all the allowable types. Could you do that Hong?

Comment by Hong Zhang [ 26/Oct/12 ]

Yeah, I will do that.





[GLASSFISH-14059] list-components, list-applications and list-application-refs output could be more user friendly Created: 18/Oct/10  Updated: 23/Oct/12  Resolved: 23/Oct/12

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: 4.0_b59

Type: Improvement Priority: Major
Reporter: shreedhar_ganapathy Assignee: Jeremy_Lv
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: XML File domain.xml     Zip Archive GLASSFISH-14059_revised_source.zip    
Issuezilla Id: 14,059

 Description   

Used latest 3.1 nightly b24 dated Oct 16th, 2010

To reproduce,
1. Start domain
2. create a cluster of two or more instances, and start it.
3. deploy any application to the cluster (in my example I used clusterjsp with availabilityenabled=true)
4. asadmin list-applications - shows Nothing to list
5. asadmin list-application-refs - shows Nothing to list

Sample output from my deployment :
dhcp-santaclara22-1fl-west-10-132-181-151:bin shreed$ ./asadmin deploy –
availabilityenabled=true --target shreedhar-cluster
~/glassfish/samples/quickstart/clusterjsp/clusterjsp.ear
Application deployed with name clusterjsp.

Command deploy executed successfully.
dhcp-santaclara22-1fl-west-10-132-181-151:bin shreed$ ./asadmin list-applications
Nothing to list.

Command list-applications executed successfully.
dhcp-santaclara22-1fl-west-10-132-181-151:bin shreed$ ./asadmin list-application-refs
Nothing to list.

Command list-application-refs executed successfully.
dhcp-santaclara22-1fl-west-10-132-181-151:bin shreed$



 Comments   
Comment by shreedhar_ganapathy [ 18/Oct/10 ]

Created an attachment (id=5161)
Domain xml attached for reference

Comment by Tom Mueller [ 18/Oct/10 ]

The default target for the list-applications command is the DAS, i.e., "server".
Did you try:

asadmin list-applications shreedhar-cluster

?

Comment by shreedhar_ganapathy [ 18/Oct/10 ]

I tried
./asadmin list-applications --target shreedhar-cluster
assuming that the --target would be more consistent with commands involving targets
That obviously failed but I just tried what you've suggested :
./asadmin list-applications shreedhar-cluster
That worked :

dhcp-santaclara22-1fl-west-10-132-181-151:bin shreed$ ./asadmin list-applications shreedhar-
cluster
ShoppingCart <web>
clusterjsp <ear, web>

Seems like a usability gap in that there is no obvious information from the command when executed as
is. Aren't all applications deployed to the domain regardless of what target they are ultimately deployed
to? It'd be nice to have this command show deployed apps with their targets

Aside, I expected list application refs to provide references to the app in the domain.

Comment by Hong Zhang [ 18/Oct/10 ]

If you want to list all the applications deployed to this domain, you need to
use the "domain" target:

asadmin list-components domain

As Tom said, the default target is DAS (the DAS target means the default server
instance, not the domain).

This syntax is used in v2 and the previous releases.

Comment by shreedhar_ganapathy [ 18/Oct/10 ]

Hong, Tom
Based on your feedback I have marked this as an enhancement. IMO the command output could give a bit
more specific info that there is no app deployed 'to the domain' or perhaps a hint that components/apps
could be found on other targets.

Comment by Hong Zhang [ 23/Mar/11 ]

target for 3.2

Comment by Tom Mueller [ 17/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.

Comment by Jeremy_Lv [ 19/Oct/12 ]

Hong:

Hong, Tom
Based on your feedback I have marked this as an enhancement. IMO the command output could give a bit
more specific info that there is no app deployed 'to the domain' or perhaps a hint that components/apps
could be found on other targets.

shall we add some infos about this phenomenon in the latest trunk?

for example´╝Ü
>asadmin list-applications
There is no applications REF by server
Nothing to list
Command list-applications executed successfully

BTW, I will look into it if it is needed to be add some infos.
IMO, I think it is no need to mark it as an enhancement in JIRA but add some description in the document about deployment to let the user know the default target value is server in the version of GFV4.

Comment by Hong Zhang [ 19/Oct/12 ]

It's already in the documentation that the default target is server, but I guess users don't always read documentation.

I guess the additional message will help "No applications are deployed to this target <target name>".

Comment by Jeremy_Lv [ 22/Oct/12 ]

try to add some messages about some related list commands and have attached my revised source to the JIRA. pls check it.

Comment by Hong Zhang [ 22/Oct/12 ]

Changes look pretty good. Please go ahead and check in after running the usual set of the tests.

Comment by Jeremy_Lv [ 23/Oct/12 ]

Run all of the QL tests and dev tests and all of them have passed.
Sending E:\GF_MAIN\SOURCE_1017\nucleus\deployment\admin\src\main\java\org\glassfish\deployment\admin\ListApplicationRefsCommand.java
Sending E:\GF_MAIN\SOURCE_1017\nucleus\deployment\admin\src\main\java\org\glassfish\deployment\admin\ListComponentsCommand.java
Sending E:\GF_MAIN\SOURCE_1017\nucleus\deployment\admin\src\main\java\org\glassfish\deployment\admin\LocalStrings.property
Transmitting file data .
Committed revision 56684.





[GLASSFISH-12032] DYREC-007: progress status design Created: 25/May/10  Updated: 05/Mar/13  Due: 24/May/11  Resolved: 05/Mar/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 4.0_b59

Type: New Feature Priority: Blocker
Reporter: Tom Mueller Assignee: martin.mares
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-12033 DYREC-007: progress status implementa... Resolved
blocks GLASSFISH-17591 asynchronous deployment related suppo... Closed
Issuezilla Id: 12,032

 Description   

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

Provide a mechanism to get progress status for long running operations (ex. deploy)



 Comments   
Comment by Tom Mueller [ 25/May/10 ]

Investigate and propose approach for progress status reporting

Comment by vijaysr [ 08/Jun/10 ]

Since some resources were moved out, this feature has been given a lower priority. This may be dropped
from 3.1 itself - not decided as yet.

Comment by Alexis MP [ 29/Jun/10 ]

cc

Comment by vijaysr [ 03/Aug/10 ]

Dropped for 3.1

Comment by vijaysr [ 28/Oct/10 ]

Transferring requested / planned enhancements for 3.2 to Tom to be reassigned to appropriate engineers
later

Comment by Tom Mueller [ 06/Apr/11 ]

must have for 3.2.

Comment by martin.mares [ 11/Oct/12 ]

Move fix version - 2nd ASArch meeting is scheduled on Oct 24th





Generated at Tue Apr 21 13:35:38 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.