[GLASSFISH-13939] [Regression] Deployment: exception when no target specified Created: 12/Oct/10  Updated: 28/Feb/11  Resolved: 13/Oct/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

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

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 13,939
Tags: 3_1-verified

 Description   

build: glassfish-3.1-b24-10_10_2010.zip

Click on Applications -> New. Choose an application and click OK (without
specifying a target). The following exception is printed to the screen:

type Exception report

message

descriptionThe server encountered an internal error () that prevented it from
fulfilling this request.

exception

javax.servlet.ServletException: java.lang.reflect.InvocationTargetException
while attempting to process a 'command' event for 'uploadButton'.

root cause

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while
attempting to process a 'command' event for 'uploadButton'.

root cause

java.lang.reflect.InvocationTargetException

root cause

java.lang.IllegalArgumentException: Could not find type conversion for type
"class [Ljava.lang.String;" (value = "[Ljava.lang.Object;@358e22")

note The full stack traces of the exception and its root causes are available in
the GlassFish Server Open Source Edition 3.1-SNAPSHOT logs.



 Comments   
Comment by lidiam [ 12/Oct/10 ]

Created an attachment (id=5132)
server.log

Comment by Anissa Lam [ 13/Oct/10 ]

This is fixed when Suma fixed issue# 13924.
They are of the same cause.

Comment by lidiam [ 28/Feb/11 ]

Verified in promoted build b43.





[GLASSFISH-13990] Retain SFSB state during redeployment doesn't work in cluster env Created: 14/Oct/10  Updated: 18/Feb/11  Resolved: 19/Oct/10

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

Type: Bug Priority: Critical
Reporter: mzh777 Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Attachments: Text File SFSBDriver.war    
Issuezilla Id: 13,990
Tags: 3_1-verified

 Description   

Promoted build 24.

Tested the keepstate=true option during redeployment in single domain and it
worked. The SFSB state was kept during the redeployment.

Tested the keepstate=true option for redeployment on cluster env and it failed.
The error messages on client side:
$ asadmin deploy --target=st-cluster --force --availabilityenabled=true
--keepstate=true dist/SFSBDriver.war
Application deployed with name SFSBDriver.
WARNING : Command _deploy did not complete successfully on server instance
instance101 : remote failure: Failed to load the application on instance
instance101. The application will not run properly. Please fix your application
and redeploy.
Exception while loading the app. Please see server.log for more details.
java.lang.Exception: WEB0113: Virtual server [server] already has a web module
[SFSBDriver] loaded at [/SFSBDriver]; therefore web module [SFSBDriver] cannot
be loaded at this context path on this virtual server.

The error message in server.log of instance101:
[#|2010-10-14T21:27:24.006-0700|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=15;_ThreadName=Thread-1;|Cannot
stop module ejb
java.lang.NullPointerException
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:273)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:267)
at
org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:277)

To reproduce, use the attached SFSBDriver.war:
1. asadmin deploy --target=st-cluster --force --availabilityenabled=true
SFSBDriver.war
2. asadmin deploy --target=st-cluster --force --availabilityenabled=true
--keepstate=true SFSBDriver.war



 Comments   
Comment by mzh777 [ 14/Oct/10 ]

Created an attachment (id=5146)
The testing app.

Comment by marina vatkina [ 18/Oct/10 ]

Reassigning to deployment to skip keepstate on a clustered deployment. When
done, we should make sure it is documented accordingly

Comment by Hong Zhang [ 18/Oct/10 ]

Per discussions, we will handle the situation like this:
when the target is non-DAS and keepstate is true:
1. reset the keepstate to false
2. print a warning message saying the keepstate option is ignored as this
feature is only supported for non clustering target.

Comment by Hong Zhang [ 19/Oct/10 ]

fix checked in according to what was proposed.





[GLASSFISH-13927] Node Tree: jdbc resource not deleted when pool deleted Created: 11/Oct/10  Updated: 02/Feb/11  Resolved: 13/Oct/10

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

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

Operating System: All
Platform: All


Attachments: JPEG File tree-resourceerror.JPG    
Issuezilla Id: 13,927

 Description   

build: glassfish-3.1-b24-10_10_2010.zip

Create a JDBC pool, e.g. called y, and a jdbc resource using this pool, e.g.
called z. Node tree is updated properly (though it takes time). Delete the
pool - message is displayed saying that all the resources depending on this pool
will also be deleted, click OK. The pool is removed from the nodes tree, but
the resource is not. When you click on that resource node the following
exception is printed:

exception
javax.servlet.ServletException: Target Unreachable, 'null' returned null

Once user clicks on JDBC Resources node, the tree underneath is updated to
reflect the deleted resource.



 Comments   
Comment by lidiam [ 11/Oct/10 ]

Created an attachment (id=5122)
screenshot

Comment by kenpaulsen [ 13/Oct/10 ]

Anissa and I looked at this together. She has a fix for this + a fix for images
/ expanded state not being preserved. I am transferring this to her so she can
resolve this as soon as her changes are committed. -Ken

Comment by Anissa Lam [ 13/Oct/10 ]

Instead of admingui.nav.refreshTree() for just the JDBC connection pool, refresh
starting from the JDBC nodes.

While fixing this, also realize the connectors connection pool will have similar
issue, fixed that as well.

Also notice that the state of the tree node is not preserved, ie, collapsed or
expanded, fixed that as well.

Comment by shaline [ 02/Feb/11 ]

Verified in promoted b40.





[GLASSFISH-13955] [508] cannot toggle between locations in Deploy Applications Screen Created: 13/Oct/10  Updated: 13/Dec/10  Resolved: 14/Oct/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

Type: Bug Priority: Major
Reporter: shaline Assignee: Anissa Lam
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,955
Tags: 3_1-508

 Description   

Build Used: GFV3.1 promoted build23.

Browser Used : firefox 3.6.
Os: Windows XP
In the Deploy Applications or Modules, window, we cannot toggle using the
keyboard hotkeys between the 2 radio buttons "Packaged File to be Uploaded to
the Server",and "Local Packaged File or Airectory that is Accessible from the
Enterprise server". The HOTKeys space bar, PageUP, PageDn, or Tab nothing works
, and we have to use mouse to select one of the above radio buttons.
Steps:
Use Tab key to navigate to "APplications" node in the left side, and hit "Enter"
Use Tab key to navigate all the way down until "Update Tool" , and then focus
shifts to Right hand "Deploy Applications and Modules" window.

Use Tab Key in the "Deploy Applications and Modules" window, to select the
"Location (radio button): Packaged file to be uploaded to the server.
Try to Select the other radio button, using the spacebar, or PageUP, PageDn
keys. nothing seems to work, and we have to use mouse.



 Comments   
Comment by Anissa Lam [ 13/Oct/10 ]

I looked at the deployment page and don't experience any issues you showed me.

---------------------------------------------------------
1st – cannot toggle between locations radio button.

Here is what you should do to go to the next radio button:

1. tab to the first radio button. ( Since you are in "Radio Button", you have to
use up and down arrows to get to the next radio button.)
2. press the down arrow, you will be at the "Local Package... radio button".

So, you can use up and down arrow to toggle between.

----------------------------------
2nd issue you show me about not able to bring up the file browser window, you
should use 'space bar'.
So, go to the radio button, tab to the text field, then tab again to 'Browse'
button. Now, press 'space bar' to bring up the file browser.
Same for the other 2 buttons, 'Browse Files' and 'Browse Folders...'. Use the
space bar.

--------------------------------
3rd issue you mentioned, about not able to select Virtual Servers.
I cannot reproduce this.
Once i tab into this 'selection list box', i can use up and down arrow to
high-light the vs i want, then tab to the next thing, which is the Enable checkbox.

-------------------------------

I have tested all the above on my WinXP, using both Firefox and IE7 browser.

So, sounds like i can get everything working with the keyboard. Can you try again ?

Comment by shaline [ 14/Oct/10 ]

I was able to select the radio buttons using the up/down arrow and also open up
the file upload window. But was not able to get the 3rd issue working:
I was not able to select the
"server" virtual server using up and down arrow after tabbing to Virtual servers.

Lowering the priority to P3.

Comment by shaline [ 14/Oct/10 ]

I was able to get through the issue #3, by using left/right arrow keys, and was
able to select the Virtual server..
So this bug can be closed, as the issue is not reproducible.

Comment by Anissa Lam [ 14/Oct/10 ]

Thanks for trying this out again.
So, I am closing this as works for me.





[GLASSFISH-13789] 3.1 deployment performance - thread/threadpool usage for the annotation scanning Created: 04/Oct/10  Updated: 26/Nov/10  Resolved: 14/Oct/10

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

Type: Bug Priority: Critical
Reporter: Hong Zhang Assignee: Hong Zhang
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-12022 CONFIG-003: No server startup regress... Resolved
Issuezilla Id: 13,789

 Description   

This is one of Tom's observations when he studied the 3.1 deployment profile:

==============================================
There are 2 threads that are created for each loop, and they are only used for
a single operation. Many of these threads are running the
ReadableArchiveScannerAdapter class within a FutureTask. I see that
ReadableArchiveScannerAdapter is used by the
ApplicationLifecycle.getDeployableTypes method which is called by
ApplicationLifecycle.deploy. The getDeployableTypes method calls an HK2 Parser
class that uses a fixed thread pool of size 1 to parse the WAR file. After it
is done parsing, it shutdown the the thread pool. So this explains why at
least one thread is only used once. I'm not sure what the other thread is for.
Also, since the getDeployableTypes has the following:

parser.parse(scannerAdapter, null);
parser.awaitTermination();

I'm not sure why a separate thread pool is even necessary for this.
================================

There were some follow up discussions on this between Tom, Jerome and Scott in
the email thread. I am filing this issue to track it.

I will work with Jerome to discuss how to better utilize thread pool/thread in
this case.



 Comments   
Comment by Hong Zhang [ 14/Oct/10 ]

Discussed with Jerome: create an instance of ExecutorService in the
deployment backend and pass it to the Parser through ParserContext so
the same instance of the ExecutorServices will be used to process
annotations for all deployments instead of re-creating the instance and shut it
down each time.





[GLASSFISH-13782] 3.1 deployment performance - ASURLClassLoader.appendURL, urlSet.contains() call takes more time than v3.0 Created: 04/Oct/10  Updated: 26/Nov/10  Resolved: 22/Oct/10

Status: Resolved
Project: glassfish
Component/s: classloader
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

Type: Bug Priority: Critical
Reporter: Hong Zhang Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File ASURLClassLoader.diff.txt    
Issue Links:
Dependency
blocks GLASSFISH-12022 CONFIG-003: No server startup regress... Resolved
Issuezilla Id: 13,782

 Description   

When comparing the deployment performance of 3.0 vs 3.1 using the profile data
that Tom collected, I noticed a few areas where we have regressed from 3.0, I
am filing issues to track these to see if we can undertand the cause of it and
if there are any potential improvement we could do.

The most noticeable part in the time differences for redeployment is when it's
creating the application classloader, it seems creating connector classloader
takes much longer (0.48 difference).
The calling stack:
org.glassfish.deployment.common.DeploymentContextImpl.createApplicationClassLoad
er(org.glassfish.internal.api.ClassLoaderHierarchy,
org.glassfish.api.deployment.archive.ArchiveHandler): 1.071, 1.551
com.sun.appserv.connectors.internal.api.ConnectorClassLoaderServiceImpl.createCo
nnectorClassLoaderForApplication(java.lang.String): 1.031, 1.511



 Comments   
Comment by Hong Zhang [ 04/Oct/10 ]

Additional note: the first number is from 3.0. the second number is from 3.1,
the unit is second.

Adding Tom to the Cc

Comment by Hong Zhang [ 04/Oct/10 ]

move to P2 as it's performance related

Comment by Jagadish [ 05/Oct/10 ]

setting target milestone

Comment by Jagadish [ 10/Oct/10 ]

Please find my observations :

The change in the time taken to create the connector classloader happens due to
ASURLClassLoader.appendURL.
In turn, the urlSet.contains() in ASURLClassLoader is the root cause which
accounts for about .42 seconds.

urlSet is realized as ArrayList and "list.contains()" call seems to take more
time as it iterates through the entries.
I tried to see the number of entries that get added to urlSet in v3.0 and 3.1
and it remains the same (highest being 52 for one of the classloader instances).
I am not sure what causes list.contains() to take more time in 3.1 though the
size remained the same between v3.0 and 3.1

However, I thought urlSet can be made as a LinkedHashSet and tried changing the
type. It seems to reduce the time taken significantly.
v3.0 - ClassLoaderHierarchy.getConnectorClassLoader() -> 1.164 sec.
3.1 (b23 workspace) - ClassLoaderHierarchy.getConnectorClassLoader() -> 1.6+ sec.
3.1 (changed urlSet to LinkedHashSet) - 0.464 sec.

Transferring to Sahoo for further investigation.

Comment by Jagadish [ 10/Oct/10 ]

Created an attachment (id=5112)
changes to use LinkedHashmap, QL (Web, Classic) passed with these changes

Comment by Sanjeeb Sahoo [ 12/Oct/10 ]

Thanks Jagadish for the excellent work. As per your email to me, you plan to
check in the patch, so reassigning to you.

Comment by Jagadish [ 13/Oct/10 ]

FIX INFORMATION :

svn log -v -r 41679
https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=24233

Fix will be available in 3.1-b25 / 13th-Oct-2010 nightly onwards

Comment by Hong Zhang [ 22/Oct/10 ]

Verified the fix by looking the numbers on the profiles that Tom collected with
today's build:

3.0:
0. 1.397
org.glassfish.deployment.common.DeploymentContextImpl.createApplicationClassLoad
er(org.glassfish.internal.api.ClassLoaderHierarchy,
org.glassfish.api.deployment.archive.ArchiveHandler)

3.1:
0. 0.798
org.glassfish.deployment.common.DeploymentContextImpl.createApplicationClassLoad
er(org.glassfish.internal.api.ClassLoaderHierarchy,
org.glassfish.api.deployment.archive.ArchiveHandler)





[GLASSFISH-13277] Monitoring bootstrap start-up performance problem Created: 03/Sep/10  Updated: 26/Nov/10  Resolved: 13/Oct/10

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

Type: Bug Priority: Critical
Reporter: Tom Mueller Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 13277.diff    
Issue Links:
Dependency
blocks GLASSFISH-12022 CONFIG-003: No server startup regress... Resolved
Issuezilla Id: 13,277

 Description   

Monitoring bootstrap code is probing any directory under
lib/install/applications to resource adapters that may or may not contain
flashlight probes. This cause the connector class loader to be created and cause
a long list of modules to be resolved.

Solution : we should only probe RAs when they are deployed (used) rather than at
startup.

Possible extended solution : we should extend that mechanism to all deployments
so that any Java EE deployed application can ship probes and they would become
automatically registered with our monitoring/REST tree. I am already drooling at
the possibilities...
For that, it might be as simple as writing a ProbeDeployer.



 Comments   
Comment by Nazrul [ 04/Oct/10 ]

We need a fix for this to make progress with GlassFish developer benchmark.

Comment by shreedhar_ganapathy [ 05/Oct/10 ]

Mahesh is busy with HA work.
Vince is beginning to look into this and working with Mahesh on this.

Could we get some idea about the % or absolute numbers in terms of impact of the currrent issue, that the
suggested solution is expected to overcome ?

Comment by Tom Mueller [ 05/Oct/10 ]

The overall performance regression measurements are here:

http://javaperf.sfbay.sun.com/JSPWiki/Wiki.jsp?page=V3.1StartupAndDeploymentPerformance

I don't know if all accesses of the lib/install/applications directory are due to the monitoring
bootstrap code, but here are some numbers based on analyzing the truss output of a DAS start:

1534 calls to system calls with lib/install/applications

  • 102 opens
  • 320 resolvepath
  • 1112 stat64

Based on truss timings, the code surrounding these calls accounts for about 3.1 seconds of a 44
second DAS startup time, or about 7%.

More data is available upon request.

Comment by vince kraemer [ 07/Oct/10 ]

Created an attachment (id=5094)
a first attempt at a fix. i am sure it could be improved

Comment by vince kraemer [ 07/Oct/10 ]

note on patch: QL passes

Comment by vince kraemer [ 12/Oct/10 ]

jagadish is making code changes that address this

Comment by Jagadish [ 13/Oct/10 ]
  • Made changes such that ClassLoaderHierarchy is not injected in
    MonitoringBootstrap, removed using connector-class-loader.
  • Made changes in connector-runtime to register a system-RAR for probes only
    when the RAR is bootstrapped.

This seems to give an improvement of around ~100-125 ms.
without-fix : 4.66 seconds (5 times start-stop domain avg)
with-fix : 4.53 seconds (5 times start-stop domain avg)

FIX INFORMATION :
svn log -v -r 41680
https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=24234

Fix will be available in 3.1-b25 / 13th-Oct-2010 nightly onwards





[GLASSFISH-13628] add monitoring support for deployment nodes in gui Created: 27/Sep/10  Updated: 19/Oct/10  Resolved: 19/Oct/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

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

Operating System: All
Platform: All


Issuezilla Id: 13,628

 Description   

Per discussion with Anissa, filing this issue to track it.

We added some monitoring/statistics for deployment, and we'd like to have GUI
screens for it.

I can see the monitoring output fine through the REST API once I turned on the
monitoring for deployment:
http://localhost:4848/monitoring/domain/server/deployment/lifecycle

So according to Anissa, it should not be too hard to add the GUI support for
it.

The deployment node is server/deployment/lifecycle. Please let me know if there
is any additional information needed. Thanks.



 Comments   
Comment by sumasri [ 07/Oct/10 ]

Added the target milestone.

Comment by sumasri [ 17/Oct/10 ]

Added monitoring support for deployment lifecycle in GUI. This can be accessed
via server (Admin server) tree node ->monitoring tab ->server ->tab. These
statistics will be shown if the "deployment" monitor level is HIGH.

But, the "applicationsinfo" statistic is not able to parse the data to a table
format. This is happening because there is no consistent separator character
between the columns. Please verify the GUI page to see what I am explaining here.

Please fix this and assign it back to me. I will take care of GUI part.

Comment by Hong Zhang [ 19/Oct/10 ]

Elinimate the space in the column name so the GUI could display the information
properly.





[GLASSFISH-11338] Wrong handling of EJB artifacts in WARs Created: 18/Dec/09  Updated: 18/Oct/10  Resolved: 18/Oct/10

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: 3.1_b25

Type: Bug Priority: Major
Reporter: nwegner Assignee: Hong Zhang
Resolution: Fixed Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Attachments: Zip Archive PullEJBfromWrongPlace.zip    
Issuezilla Id: 11,338

 Description   

Scenario:
A JAR with an EJB (stateless+REST)was placed in a free choosen directory of a
WAR (not in: WEB_INF/lib!). Following the spec this JAR should be ignored. This
scenario may be occure when cleint side EJBs via WebStart.

Error:
During the deployment of the WAR on Glassfish v3 via Webconsole (Notify: Don´t
deploy the example from Netbeans as exploded because it uses the wrong directory
in this case) the JAR will be found by the EJBDeplyoer. But the JAR wasn´t added
(correctly as expected) to the classpath which ends up in this exception when
EJBDeployer tries to analyze the classes:
SCHWERWIEGEND: Exception while invoking class
org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: Unable to load EJB module. DeploymentContext does
not contain any EJB Check archive to ensure correct packaging for
C:\sges-v3\glassfish\domains\domain1\applications\WebProject
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:133)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:63)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
at
org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:216)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)

at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)

at
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)



 Comments   
Comment by nwegner [ 18/Dec/09 ]

Created an attachment (id=4127)
Testcase using maven

Comment by bernd_zedv [ 18/Dec/09 ]
      • Issue 11338 has been confirmed by votes. ***
Comment by Hong Zhang [ 18/Dec/09 ]

The cause of the problem (ejb container when asked to load the ejbs, could not
find the corresponding ejb metadata):
1. The code to scan the archive to determine which sniffers/containers are
involved scans all the jars in the archive. So the EjbSniffer was retrieved and
ejb container is asked to load the ejb components of the application.
2. The meta-data processing part scans the correct list (only WEB-INF/lib for
war) for annotation processing. So no ejb part of the metadata is processed.

Need to look into if we can only scan the correct list of jars in part 1).

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 18/Oct/10 ]

we now are looking at the correct list of the jars in part 1) also





[GLASSFISH-14024] 3.1 inline help refers to "Enterprise Server", not "GlassFish Server" Created: 15/Oct/10  Updated: 15/Oct/10  Resolved: 15/Oct/10

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

Type: Bug Priority: Major
Reporter: Mike Fitch Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,024

 Description   

Several inline help phrases refer to the product as "Enterprise Server". It has
been "GlassFish Server" over a release now, and should be changed.



 Comments   
Comment by Mike Fitch [ 15/Oct/10 ]

Fix commited in revision 41781.

Comment by Anissa Lam [ 15/Oct/10 ]

Specify the Target milestone.





[GLASSFISH-13735] remove AMX dependency Created: 30/Sep/10  Updated: 14/Oct/10  Resolved: 14/Oct/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

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

Operating System: All
Platform: All


Issuezilla Id: 13,735

 Description   

We really need to remove AMX dependency from the console.
Please refer to

https://glassfish.dev.java.net/nonav/issues/showattachment.cgi/5028/handler.jpg
and
https://glassfish.dev.java.net/nonav/issues/showattachment.cgi/5029/jsf.jpg

Jaons: JmsHandlers.java

Srini: CorbaHandlers.java
InstanceHandlers.java (LOTS of handler related to the JVM pages)
SecurityHandler.java
WebHandlers.java

Ken: LoggingHandlers.java
LogViewHandlers.java

I will take care of the rest.

If these are obsolete code, please remove it. If not, it means that function
will be broken, please comment that out and file a bug against yourself.



 Comments   
Comment by Anissa Lam [ 14/Oct/10 ]

All AMX dependency has been removed from the GUI code.
There are a couple known issue, including: get/set logger attributes, get/set logger level, log viewer and
System Properties.
I have opened individual issues to keep track of them.

Marking this bug resolved.





[GLASSFISH-13803] appclient launch page always choose the first link Created: 04/Oct/10  Updated: 14/Oct/10  Resolved: 14/Oct/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

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

Operating System: All
Platform: All


Issuezilla Id: 13,803

 Description   

When there are more than 1 link to launch the app client, its always the first
link in the list, regardless what the user choose.



 Comments   
Comment by Anissa Lam [ 14/Oct/10 ]

The page now uses the correct link that user selected.
However, due to issue# 13796, some of the link may have $

{HTTP_PORT}

etc, if
you can click on the link where the port is not resolved to a valid port #, GUI
will lost its layout. Just click the 'back' button to wait for it to get back
to the General page.
Once bug# 13796 is fixed, you won't see this kind of wrong link.





[GLASSFISH-12953] EJB Container Settings page radio buttons does not work Created: 11/Aug/10  Updated: 13/Oct/10  Resolved: 13/Oct/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_b25

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

Operating System: All
Platform: All


Issuezilla Id: 12,953

 Description   

Radio button in EJB Settings under EJB Container is failing.

To reproduce -> Select commit option B in EJB Settings page in EJB Container.
Save does not succeed. If you use commit option C it works fine.



 Comments   
Comment by srinik76 [ 28/Sep/10 ]
      • Issue 13251 has been marked as a duplicate of this issue. ***
Comment by Anissa Lam [ 02/Oct/10 ]

-> Srini

Comment by srinik76 [ 04/Oct/10 ]

Reassigning to Ken to look into this

Comment by Anissa Lam [ 07/Oct/10 ]

-> jdlee

Comment by Jason Lee [ 07/Oct/10 ]

Please fix the issue or document why you are unable to. Thanks.

Comment by srinik76 [ 08/Oct/10 ]

When the user selects Option C in Ejb Contianer -> Ejb Settings the valueMap
printed is

Printed the following debug message in editPageButtons_2.inc

[#|2010-10-08T12:27:07.692+0530|INFO|glassfish3.1|null|_ThreadID=14;_ThreadName=Thread-1;|***
The valueMap is {victimSelectionPolicy=nru, steadyPoolSize=0,
cacheResizeQuantity=32, maxCacheSize=512,
sessionStore=$

{com.sun.aas.instanceRoot}/session-store, maxPoolSize=32,
cacheIdleTimeoutInSeconds=600, removalTimeoutInSeconds=5400,
poolIdleTimeoutInSeconds=600, poolResizeQuantity=8, commitOption=C}|#]


When Option B is selcted the valueMap is

[#|2010-10-08T12:27:13.043+0530|INFO|glassfish3.1|null|_ThreadID=14;_ThreadName=Thread-1;|***
The valueMap is {victimSelectionPolicy=nru, steadyPoolSize=0,
cacheResizeQuantity=32, maxCacheSize=512,
sessionStore=${com.sun.aas.instanceRoot}

/session-store, maxPoolSize=32,
cacheIdleTimeoutInSeconds=600, removalTimeoutInSeconds=5400,
poolIdleTimeoutInSeconds=600, poolResizeQuantity=8, commitOption=null}|#]

commitOption should be B but comes as null.

Do not know why this is happening? Need help in debugging this?

Comment by srinik76 [ 08/Oct/10 ]

Discussed with Irfan and Suma, they are not able to find why this is happening?
Ken asked to raise a bug and assign to him so that he will look into this.

Comment by Jason Lee [ 08/Oct/10 ]

Please take a look at the virtual server issue you closed this morning and see how it handles the radio
button. Apply that here.

Comment by srinik76 [ 11/Oct/10 ]

Send a mail to Anissa to find out if this can be assigned again to ken, to look
into this.

Comment by srinik76 [ 12/Oct/10 ]

There is a issue with the radio buttons used. Need help from ken on this.

Comment by Anissa Lam [ 13/Oct/10 ]

-> anilam

Comment by Anissa Lam [ 13/Oct/10 ]

Add a hidden field to track the value of radio button selected."

/Users/anilam/Awork/V3/v3/admingui/ejb-lite/src/main/resources/configuration/ejbContainerGeneral.jsf
Sending
/Users/anilam/Awork/V3/v3/admingui/ejb-lite/src/main/resources/configuration/ejbContainerGeneral.jsf
Transmitting file data ...
Committed revision 41688.





Generated at Tue Sep 27 04:55:53 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.