<< Back to previous view

[GLASSFISH-16200] Common Tasks: Broken Doc Links Created: 13/Mar/11  Updated: 26/Apr/11  Resolved: 26/Apr/11

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

Type: Bug Priority: Major
Reporter: Harald Wellmann Assignee: Paul Davies
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved 3_1-fishcat
Participants: Anissa Lam, Harald Wellmann and Paul Davies

 Description   

The Documentation links on the Common Tasks welcome page are broken. They all link or redirect to http://www.oracle.com/pls/topic/error.



 Comments   
Comment by Harald Wellmann [ 13/Mar/11 09:18 AM ]

As I cannot reopen GLASSFISH-15663, I created this clone.

With Glassfish 3.1 (the release, aka b43), the links on the Admin Console start page are broken again.

The URLs listed by Paul Davies in GLASSFISH-15663 seem to have changed again. I get the same error message when directly pointing my browser at these URLs.

Comment by Anissa Lam [ 13/Mar/11 12:42 PM ]

Request Paul to follow up on this.
This was from the latest email from Paul when i requested him to double check the doc link.

==================================
Hi Anissa,

I have cross-checked the URLs that I gave you with the URLs in the svn diff output in the comment that you added to the bug and I can confirm that they are correct.

I have much greater confidence in these URLs as they were generated automatically by our link management system and match the URLs that will be in the Preface of all the books when they're published on OTN.

I only wish that I had had this information when I gave you the original URLs.

Regards,
-Paul

On 01/26/11 23:03, Anissa Lam wrote:
>
> Component: admin_gui
> Issue: http://java.net/jira/browse/GLASSFISH-15663
>
> I have once again updated the doc link in the common task page according to the new info thats provided by the doc team. There is no way to verify the link is correct. Request Paul to review the link again.
>
> thanks
> Anissa.





[GLASSFISH-14893] Message Security :Selecting Default Provider and Default Client Provder throws Exception Created: 30/Nov/10  Updated: 28/Feb/11  Resolved: 31/Jan/11

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

Type: Bug Priority: Trivial
Reporter: shaline Assignee: srinik76
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Solaris SParc 10
Browser: firefox 3.6


File Attachments: Text File gui-common.patch    
Tags: 3_1-apporved 3_1-verified
Participants: Anissa Lam, Chris Kasso, Jason Lee, shaline and srinik76

 Description   

Build Used : nightly dated 11/29

In server-config/security/Message Security, select SOAP and Message Security tab. Select an option like, "Server Provider" for Default Provider, and "Client Provider" for Default client Provider in the drop down menus.
Click the SAVE button: we get the below Exception:
An error has occurred
org.jvnet.hk2.config.ValidationException: Constraints for this bean violated. Message = defaultProvider must match "[\p{L}\p{N}_][\p{L}\p{N}-_./;#]*"


server.log has the below message:
[#|2010-11-30T13:34:50.982-0800|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=15;_ThreadName=Thread-1;|RestResponse.getResponse() failed. endpoint = 'http://localhost:4848/management/domain/configs/config/server-config/security-service/message-security-config/HttpServlet'; attrs = '{defaultClientProvider=null, authLayer=HttpServlet, DefaultProvider=GFConsoleAuthModule, DefaultClientProvider=, defaultProvider=null}'; RestResponse: {"message":"org.jvnet.hk2.config.ValidationException: Constraints for this bean violated. \n Message = defaultClientProvider must match \"[\\p{L}
p{N}_]
\\p{L}\\p{N}\\-_.\/;#*\"","exit_code":"FAIL
URE"}"|#]



 Comments   
Comment by srinik76 [ 05/Dec/10 10:53 PM ]

Works fine with the latest build. Looks like this issue is because of 14682, the fix for 14682 is checked in.

Comment by shaline [ 26/Jan/11 03:59 PM ]

This issue exists on promoted b38. When we select a Default client and a Default provider. The Exception is not seen, but the Default values are not set . In the "Message Security Configurations" table notice that the fields are empty for Default Client, and Default Server Providers, for SOAP and HttpServlet, even though it said "Values saved succesfully ".

Comment by Chris Kasso [ 26/Jan/11 04:18 PM ]

Confirmed with Anissa that this is not a stopper. Excluding from 3.1.

Comment by Anissa Lam [ 27/Jan/11 12:31 AM ]

How bad is its impact? (Severity)
medium. This is a regression from v3.

How often does it happen? (Frequency)
whenever user wants to set the Default client and Default Provider for any Message Security Layer

How much effort is required to fix it? (Cost)
2 hours

What is the risk of fixing it? (Risk)
low

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
User will have to use CLI set command

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes

While working on this, also notice that the cancel link will cancel to point to "server-config" whenever you go to edit the Provider from the top level MessageSecurity table. So, also fixing it here.

the orig. diff removed to avoid confusion. please see next comment and review the patch.

Comment by Anissa Lam [ 27/Jan/11 12:42 PM ]

As i looked at the different pages related to message-security, I see many issue. I have fixed a couple more. Please review the attached diff.

Issue fixed:

  • Display/Saving Default Provider and Default Client provider correctly in Edit Msg Security page
  • create Provider now creates to the correct config, instead of always created under 'server-config'.
  • The Providers table correctly sepcify 'true' or 'false' for the 'Default Provider' column
  • Edit provider page Cancel button goes to the correct Configuration, instead of going to 'server-config' if you come to this page by clicking on the links provided in the top level Msg. Security Config page.
  • Provider Type and ClassName in Edit Provider page now saved correctly.
  • Response Policy in Edit Provider page now displayed correctly.
  • When creating new Provider, used to failed silently , eg. when creating duplicate provider with the same name. Fixed to use restRequest() and display error/warning if needed.
  • There is one more issue which i didn't fix, since thats basically not done yet. I filed GLASSFISH-15711 for Srini to work on.

Please review the attached patch.

Comment by Jason Lee [ 27/Jan/11 12:56 PM ]

Changes look fine.

Comment by Anissa Lam [ 27/Jan/11 01:07 PM ]

Project: glassfish
Repository: svn
Revision: 44754
Author: anilam
Date: 2011-01-27 21:05:39 UTC
Link:

Log Message:
------------
GLASSFISH-14893. Many issues related to Msg Security and Provider pages. Refer to the bug report the list of fixes.

Approve: Anissa
Reviewer: Jason.

Revisions:
----------
44754

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/resources/security/msgSecurity/msgSecurity.jsf
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/SecurityHandler.java
trunk/v3/admingui/common/src/main/resources/security/msgSecurity/providerAttr.inc
trunk/v3/admingui/common/src/main/resources/security/msgSecurity/msgSecurityEdit.jsf
trunk/v3/admingui/common/src/main/resources/security/msgSecurity/providerEdit.jsf

Comment by srinik76 [ 27/Jan/11 10:13 PM ]

Reassigning to me to track to add dev test for the cases fixed

Comment by srinik76 [ 27/Jan/11 10:13 PM ]

Changing the priority to trivial, bcos since only the dev test needs to be added

Comment by srinik76 [ 31/Jan/11 05:39 PM ]

shaline added tests for this.
Hi Anissa,
I added new tests as you have mentioned below for Msg security related pages and verified them on promoted b40. All the fixes are working. Thanks for fixing them.

So closing the bug





[GLASSFISH-15687] Error when admin-listener/SSL and HTTP tabs are clicked with secure-admin-enabled Created: 25/Jan/11  Updated: 21/Feb/11  Resolved: 27/Jan/11

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

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

OS: Solaris Sparc 10. Browser firefox 3.6


File Attachments: Text File admingui.patch    
Tags: 3_1-approved 3_1-verified
Participants: Anissa Lam, shaline and sirajg

 Description   

GF build. Nightly dated b39-01/25/2011

Enable secure admin in CLI and bring up Console.
Select server-config/Network-Config/Network-listeners/admin-listener
Click on admin-listeners SSL tab.
We get the below Error:
An error has occurred
REST Request 'https://localhost:4848/management/domain/configs/config/server-config/network-config/protocols/protocol/pu-protocol/ssl.json' failed with response code '404'.

Click on FileCache Tab: we get
An error has occurred
OPTIONS https://localhost:4848/management/domain/configs/config/server-config/network-config/protocols/protocol/pu-protocol/http/file-cache returned a response status of 404

Click on HTTP tab of admin-listener:
we get
HTTP Status 500 -
type Exception report
javax.servlet.ServletException: java.lang.RuntimeException while attempting to process a 'beforeCreate' event for 'event220

The same issue is seen when pu-protocol, and admin-http-redirect protocol is selected and HTTP, and FileCache tabs are clicked for these 2 protocols.



 Comments   
Comment by Anissa Lam [ 25/Jan/11 03:57 PM ]

This is because GUI has decided not to support the lower level Grizzly configuration, like port-unification, protocol-finder etc. when doing the 3.1 planning. Reason being that we don't expect GlassFish user be using that.

<protocol name="pu-protocol">
<port-unification>
<protocol-finder protocol="sec-admin-listener" name="http-finder" classname="com.sun.grizzly.config.HttpProtocolFinder"></protocol-finder>
<protocol-finder protocol="admin-http-redirect" name="admin-http-redirect" classname="com.sun.grizzly.config.HttpProtocolFinder"></protocol-finder>
</port-unification>
<ssl classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname=""></ssl>
</protocol>

<network-listener port="4848" protocol="pu-protocol" transport="tcp" name="admin-listener" thread-pool="admin-thread-pool"></network-listener>

However, it turns out that secure-admin is based on that. Thats why, when you go to the HTTP or FileCache tab for the admin-listener, you are seeing the exception.

We will not be able to support the configuration of admin-listener when secure-admin is on. It is too late to add any of the feature now.
We will either hide the HTTP or File Cache tab or print out the msg for user to use CLI to configure admin-listener instead of using GUI.

Comment by Anissa Lam [ 26/Jan/11 10:48 PM ]

How bad is its impact? (Severity)
Pretty secure as we are seeing exception on screen.

How often does it happen? (Frequency)
Whenever secure-admin is turned on, and use goes to the edit admin-listener or the new protcol thats created due to secure-admin.

How much effort is required to fix it? (Cost)
1-1/2 days

What is the risk of fixing it? (Risk)
we are just hiding the tabs, really not changing any of the logic. So, it is very easy to see if the change is working correctly.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No workaround.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Probably won't help. User will just see the exception on screen. No work around for them anyway.

Comment by Anissa Lam [ 26/Jan/11 10:49 PM ]

I have made the following changes, the patch attached.

  • when init Session Attribute, test if secure-admin is enabled, and save that in the sessionMap since we will need this often.
  • When edit Network Listener, If secure-admin is turned on, then test if the name of this listener is the one specified for the Virtual Server __asadmin. If it is, the following will happen:
  • SSL Tab, HTTP Tab and FileCache will be hidden.
  • When edit Protocol, Test if secure-admin is turned on, and this protocol is the one used by the listener of the the virtual server, __asadmin'. If it is, the following will happen:
  • SSL Tab, HTTP Tab and FileCache Tab will be hidden.
  • Save Button will be disabled. We don't want user to change the secure-enable setting for this protocol.
  • These 2 additional protocol will also behave as above, "sec-admin-listener' and 'admin-http-redirect'. Right now, it is hardcoded to these 2 names, since user will not be able to change this easily. In 3.2, we may want to revisit if we decide to support the other grizzly config element.

Since I need to enable/disable the Save button, I just have the button in the jsf page, instead of including editPageButtons.inc from /common/share. It is pretty straight forward.

I have ran the NetworkConfigTest devtest (although very limited now) for both case: enable/disable secure admin, and the 3 tests pass.

Comment by sirajg [ 27/Jan/11 09:05 AM ]

In common/src/main/java/org/glassfish/admingui/common/util/GuiUtil.java
instead of "true".equals(secureAdminAttrs.get("enabled"))))
better to use proper boolean comparision
Otherwise changes look good.

Comment by Anissa Lam [ 27/Jan/11 09:29 AM ]

thanks Siraj for reviewing. The line is changed to
if (Boolean.parseBoolean((String)secureAdminAttrs.get("enabled"))).

Fix checked in.

Project: glassfish
Repository: svn
Revision: 44742
Author: anilam
Date: 2011-01-27 17:22:01 UTC
Link:

Log Message:
------------
GLASSFISH-15687. Do not allow editing for the auto-created protocol and admin-listener when secure-admin is enabled.
The change include:

  • when init Session Attribute, test if secure-admin is enabled, and save that in the sessionMap since we will need this often
  • the SSL tab, HTTP tab and File Cache tab will not be displayed accordingly.
  • the Save button will not be enable for those protocols and admin-listener.

Approve: Anissa
Reviewer: Siraj.

Revisions:
----------
44742

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/util/GuiUtil.java
trunk/v3/admingui/web/src/main/resources/grizzly/protocolEdit.jsf
trunk/v3/admingui/web/src/main/resources/grizzly/protocolTabs.inc
trunk/v3/admingui/web/src/main/resources/grizzly/networkListenerEdit.jsf
trunk/v3/admingui/web/src/main/resources/grizzly/listenerTabs.inc

Comment by shaline [ 10/Feb/11 02:32 PM ]

Verified in b42 nightly dated 02-09-2011





[GLASSFISH-15728] jpa appScopedResource failure on MS SQL server Created: 27/Jan/11  Updated: 17/Feb/11  Resolved: 02/Feb/11

Status: Resolved
Project: glassfish
Component/s: sqe-test
Affects Version/s: 3.1
Fix Version/s: 3.1_b40

Type: Bug Priority: Major
Reporter: sherryshen Assignee: sherryshen
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

solaris and linux


Tags: 3_1-verified
Participants: Jagadish and sherryshen

 Description   

glassfisg-3.1-b39.zip
jpa failure in @DSD and AppScopedResource on Microsoft SQL server.
These tests passed on Derby.



 Comments   
Comment by sherryshen [ 27/Jan/11 09:32 PM ]

To reproduce the failure:
set env with referece of
http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=V31CoreInstruction
where db info is in workspace
appserver-sqe/build-config/microsoft_datadirect.properties
To run test,
cvs co appserver-sqe/bootstrap.xml
cd $SPS_HOME
ant -f bootstrap.xml co-ejb > /dev/null
ant start-domain
ant microsoftdd-setup
cd pe/ejb/jpa20/war/criteriaquerydsd
ant microsoftdd all_sql | tee test1.output (jpa sql with dsd, failed)
cd pe/ejb/jpa20/war/criteriaquery
ant microsoftdd all | tee test2.output (jpa j2db)
ant microsoftdd all_as | tee test3.output (jpa j2db with appScopedResource, failed)

http://sqe-hudson.us.oracle.com:8080/hudson/job/sherry-ejbd-das/
#13
JPA2-criteriaquerydsd-war-sql-createDataID 2 failed.
JPA2-criteriaquery-war-j2db-createDataID 2 passed.
JPA2-criteriaquery-war-j2db-appScopedResources-createDataID 2 failed.

client and server error in test3 can be found fron
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build39/dbtest/appscoped.txt

Comment by Jagadish [ 27/Jan/11 10:42 PM ]

The real issue is due to the fact that Microsoft DTC (Distributed Transaction Coordinator) is not running (or installed) in the MS SQL server setup being used here.

When the resource-type is XADataSource, in case of MS SQL Server DTC will be needed.

1) Currently, appserver-sqe/pe/ejb/jpa20/war/criteriaquery/build.xml uses default resource-type
while creating jdbc-connection-pool ie., "javax.sql.DataSource" and hence it passes.

Change the build.xml ( appserver-sqe/pe/ejb/jpa20/war/criteriaquery/build.xml ) to use
XADataSource for the jpa test, which will also start failing.

===================================================================
RCS file: /m/jws/appserver-sqe/pe/ejb/jpa20/war/criteriaquery/build.xml,v
retrieving revision 1.3
diff -r1.3 build.xml
110c110,112
< <antcall target="create-jdbc-connpool-common"/>

> <antcall target="create-jdbc-connpool-common">
> <param name="jdbc.resource.type" value="javax.sql.XADataSource"/>
> </antcall>

2) For app-scoped-resources, change the glassfish-resources.xml to :
===================================================================
RCS file: /m/jws/appserver-sqe/pe/ejb/jpa20/war/criteriaquery/descriptor/glassfish-resources.xml_db,v
retrieving revision 1.1
diff -r1.1 glassfish-resources.xml_db
9c9
< res-type="javax.sql.XADataSource" name="java:app/jpa2cq-pool">

> res-type="javax.sql.DataSource" name="java:app/jpa2cq-pool">

The test will pass.

3) w.r.t @DSD based test failure, there is no equivalent way to specify "resource-type" in @DSD.
In this particular case of datasource-class, "com.ddtek.jdbcx.sqlserver.SQLServerDataSource", it is an implementation of all 3 types of datasource ie., javax.sql.DataSource, javax.sql.ConnectionPoolDataSource, javax.sql.XADataSource.
With no way to specify the exact data-source-type (equivalent of "resource-type" in jdbc-connection-pool) this class need to be used as, most specific type ie., javax.sql.XADataSource will be derived. Since the MS-SQL installation does not have DTC, it will fail.
Fix would be to either use DTC or exclude this test against MS-SQL.

Comment by sherryshen [ 28/Jan/11 09:27 AM ]

Thank Jagadish for the analysis and guiding me to understand the problem.

1) I consulted Dennis MacConnell about DTC service on Microsoft SQL Server.
From Dennis, "It did look like the DTC service is configured (and running)."
Then, I did more test on one suite
appserver-sqe/pe/ejb30/persistence/pkgEarTest9/
since I found a record the tests passed xa data source on b36 and Jan. 5, 2011.
ttp://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build36/dbtests/mssql2008/ejb/html/test_results_ejb3.html
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build36/dbtests/mssql2008/ejb/output/ejb30_pkgEarTest9.output
I haven't changed this test suite for months.

2) If I use original glassfish-resources.xml with xa data source, the tests failed today
(Jan. 28, 2011)on b36 and b39 with DTC error
[echo] Caused by: java.sql.SQLException: Error in allocating a connection. Cause:
Connection could not be allocated because:
[DataDirect][SQLServer JDBC Driver][SQLServer]Failed to initialize DTC. Check if DTC service is running.

<resources>
<jdbc-connection-pool
datasource-classname="com.ddtek.jdbcx.sqlserver.SQLServerDataSource"
res-type="javax.sql.XADataSource" name="java:app/pkgEarTest9-pool">
<property name="User" value="cts1"/>
<property name="Password" value="cts1"/>
<property name="serverName" value="jsepc11.east.sun.com"/>
<property name="portNumber" value="1433"/>
<property name="dataBaseName" value="cts5" />
<property name="url" value="jdbc:datadirect:sqlserver://jsepc11.east.sun.com:1433" />
</jdbc-connection-pool>
<jdbc-resource pool-name="java:app/pkgEarTest9-pool"
jndi-name="java:app/jdbc/pkgEarTest9" />
</resources>

3) If I change glassfish-resources.xml with non-xa dada source, the tests passed on b39.
<resources>
<jdbc-connection-pool
datasource-classname="com.ddtek.jdbcx.sqlserver.SQLServerDataSource"
res-type="javax.sql.DataSource" name="java:app/pkgEarTest9-pool">
<property name="User" value="cts1"/>
<property name="Password" value="cts1"/>
<property name="serverName" value="jsepc11.east.sun.com"/>
<property name="portNumber" value="1433"/>
<property name="dataBaseName" value="cts5" />
<property name="url" value="jdbc:datadirect:sqlserver://jsepc11.east.sun.com:1433" />
</jdbc-connection-pool>
<jdbc-resource pool-name="java:app/pkgEarTest9-pool"
jndi-name="java:app/jdbc/pkgEarTest9" />
</resources>
This proves that the same database is OK the tests using non-xa data source.

4) As the end, I don't know how to resolve DTC service error for XA data source.

Comment by sherryshen [ 28/Jan/11 03:46 PM ]

Based on Jagadish's analysis and my further tests.

2) For app-scoped-resources, change the glassfish-resources.xml to :
< res-type="javax.sql.XADataSource" name="java:app/jpa2cq-pool">

> res-type="javax.sql.DataSource" name="java:app/jpa2cq-pool">

I have two suites for app-scoped-resources tests
appserver-sqe/pe/ejb/jpa20/war/criteriaquery war
appserver-sqe/pe/ejb30/persistence/pkgEarTest9 ear
For war suite, I revised it to Non-XA DataSource as Jagadish suggested.
For ear suite, I left it with XA DataSource for different coverage.
Tests for No-XA data source passed on microsoftdd and sybasedd.
Tests for XA data source failed on microsoftdd and sybasedd.

3) w.r.t @DSD based test failure, there is no equivalent way to specify "resource-type" in @DSD.
Fix would be to either use DTC on MS-SQL (need help on how?).
I filed another bug to track the fix for failure on SyBase
http://java.net/jira/browse/GLASSFISH-15744

Comment by sherryshen [ 02/Feb/11 09:08 AM ]

Trouble Shooting note about MSSQL DTC issue.

1) Dennis MacConnell
It did look like the DTC service is configured (and running). The only difference from my side
was a reboot and Microsoft patch install (KB2419632). I just removed the patch and
rebooted the machine.

2) Sherry Hill
sqe ejb tests with @DSD using XA still failed with DTC error.

3) Mitesh Meswani
Here is what I got "googling" for the error. Can you please check following
http://uxforums.progress.com/ddforums/thread.jspa?threadID=571

This error message is generated when the SQL Server extended stored procedures needed by the JDBC driver can not create the necessary COM interfaces it needs to communicate with the DTC server.

On the machine the SQL Server instance to which you are connecting to is running, look for a file named sqljdbc.log. In that file look for the message "DTC Component interfaces initialization failed". The messages following that may provide some additional insight as to why communication with the DTC service could not be established.

5) Dennis MacConnell
I think I got the DTC service thing resolved. I was able to reproduce it running some of the CTS tests.
Using google I found a similar issue and followed the intructions from their the workaround. (It was pretty much reinstalling it).

6) Sherry Hill
The sqe ejb tests with @DSD using XA passed on Microsoft SQL server.

Comment by sherryshen [ 02/Feb/11 09:11 AM ]

The tests passed on v3.1 b40 after Dennis resolved DTC issue
on Microsoft SQL server.
Thank Dennis for the great support on db.
Thank Jagadish and Mitesh for analysis and suggestion about test failure.





[GLASSFISH-15694] Admin GUI - Instance Properties : missing online help Created: 26/Jan/11  Updated: 02/Feb/11  Resolved: 27/Jan/11

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

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

Tags:
Participants: Anissa Lam, Chris Kasso and Harshad Vilekar

 Description   

Steps: Create and start a cluster (cluster1) of two instances (instance1, instance2)

Clusters - cluster1 - instances - instance1 - Properties - Help

— server log ----
[#|2011-01-26T11:25:31.252-0800|INFO|oracle-glassfish3.1|com.sun.jsftemplating|_ThreadID=34;_ThreadName=Thread-1;|JSFT0004: The requested resource (/cluster/en/help/help_cluster.clusterInstanceConfigProperties) is not available.|#]

[#|2011-01-26T11:26:45.391-0800|INFO|oracle-glassfish3.1|com.sun.jsftemplating|_ThreadID=27;_ThreadName=Thread-1;|JSFT0003: VariableResolver was unable to find key (clusterInstanceConfigProperties) in ResourceBundle (help_cluster).|#]

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



 Comments   
Comment by Chris Kasso [ 26/Jan/11 04:05 PM ]

This issue is being excluded from 3.1. It is not a stopper.

Comment by Anissa Lam [ 27/Jan/11 01:51 PM ]

simple fix in properties file. there was a typo there.

clusterInstanceConfigProperties=ref-clusterinstanceconfigproperties.html

Comment by Harshad Vilekar [ 02/Feb/11 11:07 AM ]

Verified: 3.1 b41 nightly.





[GLASSFISH-15693] Admin GUI - System Properties : missing online help Created: 26/Jan/11  Updated: 02/Feb/11  Resolved: 27/Jan/11

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

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

Tags: 3_1-approved
Participants: Anissa Lam, Chris Kasso and Harshad Vilekar

 Description   

Configurations - server-config - System Properties - Help

— server log ----
[#|2011-01-26T10:26:49.958-0800|INFO|oracle-glassfish3.1|com.sun.jsftemplating|_ThreadID=25;_ThreadName=Thread-1;|JSFT0004: The requested resource (/common/en/help/=======) is not available.|#]
---- ----



 Comments   
Comment by Chris Kasso [ 26/Jan/11 04:05 PM ]

This issue is being excluded from 3.1. It is not a stopper.

Comment by Anissa Lam [ 27/Jan/11 01:37 PM ]

Simple fix, the online help key is not correct.

-configurationSystemProperties========
+configurationSystemProperties=ref-configurationsystemproperties.html

Comment by Harshad Vilekar [ 02/Feb/11 10:46 AM ]

Verified: 3.1 build 41 nightly.





[GLASSFISH-15592] [STRESS] Slow Memory growth observed over 24x7. Created: 17/Jan/11  Updated: 01/Feb/11  Resolved: 01/Feb/11

Status: Resolved
Project: glassfish
Component/s: failover
Affects Version/s: 3.1_b37
Fix Version/s: 3.1_b40

Type: Bug Priority: Critical
Reporter: varunrupela Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: JPEG File cpu-mem.jpg     File instance101-jmap-live.out-1     File instance101-jmap-live.out-34     File instance101-jmap-live.out-67    
Issue Links:
Dependency
blocks GLASSFISH-15423 [STRESS] [BigApps] [Umbrella-Issue] 2... Closed
Tags: 3_1-review
Participants: Mahesh Kannan, Nazrul and varunrupela

 Description   

Details of the scenario are in the parent issue for this bug: http://java.net/jira/browse/GLASSFISH-15423

The re-run of this RichAccess 24x7 scenario with build 37 shows slow but evident memory growth. One of the instance's (instance101) jmap (-histo:live) logs were taken every 20 minutes. Three of those are attached here and so is the CPU/Mem plot. The jmap -dump and the -histo:lie logs will be sent directly to Mahesh.

The jmap -histo:live log files from the instance indicate a slow rise in number/size the following data structures:

  • org.shoal.ha.cache.impl.store.DataStoreEntry
  • java.util.concurrent.ConcurrentHashMap$HashEntry
  • com.sun.ejb.base.sfsb.util.SimpleKeyGenerator$SimpleSessionKey

The observed memory growth is perhaps slow due to the low number of simultaneous users (100 per instance).



 Comments   
Comment by Mahesh Kannan [ 18/Jan/11 04:25 PM ]

Varun,
Did we see the growth on b36? There were no major changes in the replication module since b36.
Can you point me to the server logs? One possibility is that instance1 could be acting as replica for more keys than the other two instances.

FYI, SimpleSessionKeys are used as Keys for EJBs.

Comment by varunrupela [ 18/Jan/11 08:39 PM ]

Checked all the older runs, there was only one run with nightly build from dec 21 that showed a really really small hint of memory growth. No other runs show it.

This issue is being reported with build 37 and on Windows 2008. The other run with build 37 on OEL does not show a memory growth.

Logs location is being sent by e-mail to you.

Comment by Nazrul [ 19/Jan/11 09:44 AM ]

Any update on the memory leak?

Comment by Mahesh Kannan [ 20/Jan/11 12:25 AM ]

I looked into the two jmap s (using jhat -baseline <first map> <second map>) and it looks like the EJB references are slowly leaking. All these are residing in the ReplicaStore.

There are two reasons why they could be leaking in instance 1

1. instance 1 could be acting as replica instance for more keys than other two instances (though this means a non-uniform key distribution)

2. The save commands could be arriving after remove commands. One way to handle this is to maintain a set that contains keys that were removed in the recent past (say 5 minutes?). Then, if the save commands arrive out of order we could throw away those that arrive remove commands. Obviously, this can be implemented only in 3.2. The other option is to rely of ejb idle processor to remove unused keys. Maybe running the longivity test with a lower re-move-timeout-in-sceonds might eliminate this slow growth.

Comment by Nazrul [ 27/Jan/11 11:11 AM ]

Tracking bug at this point. Excluding from un-scrubbed list

Comment by Mahesh Kannan [ 01/Feb/11 03:41 PM ]

Elena could run richAccess for 4 days without any memory leaks. The jvm though crashed. I believe there is a separate issue for that.

I am marking this issue as resolved. Please reopen if you see this issue again.

Comment by Mahesh Kannan [ 01/Feb/11 03:43 PM ]

If you see a growth, please rerun the app with the following system property -Dorg.shoal.ha.cache.mbean.register=true





[GLASSFISH-15663] Common Tasks: Broken Doc Links Created: 23/Jan/11  Updated: 01/Feb/11  Resolved: 27/Jan/11

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

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

File Attachments: HTML File 2011-01-31-19-46-install-summary.html    
Tags: 3_1-approved 3_1-fishcat
Participants: Anissa Lam, Harald Wellmann, Paul Davies, scatari and stephanj

 Description   

The Documentation links on the Common Tasks welcome page are broken. They all link or redirect to http://www.oracle.com/pls/topic/error.



 Comments   
Comment by Anissa Lam [ 23/Jan/11 11:52 AM ]

The link points to 3.1 doc set is correct. But according to the doc team, the page will not come alive till 3.1 ships. I don't need this arrangement either.

Transfer to 'doc' team. They can verify the link one more time and mark resolve.

Doc links for 3.1
commonTasks.doc.qstart=http://www.oracle.com/pls/topic/lookup?ctx=821-2432
commonTasks.doc.adminGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2416
commonTasks.doc.devGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2418
commonTasks.doc.deployGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2417

Comment by Paul Davies [ 24/Jan/11 10:21 AM ]

If engineering feels uneasy about linking to documentation that will not be live until the product is released, all I can suggest is that the links be removed from the software.

Comment by Paul Davies [ 26/Jan/11 07:38 PM ]

After checking again with the doc tools team, I have discovered that the URLs that I was originally given were incorrect:

The correct URLs are as follows:

commonTasks.doc.qstart=http://www.oracle.com/pls/topic/lookup?ctx=821-2432&id=sjsaseeqsg
commonTasks.doc.adminGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2416&id=sjsaseeag
commonTasks.doc.devGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2418&id=sjsaseedg
commonTasks.doc.deployGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2417&id=sjsaseeadg

Note that the targets of these corrected URLs will not be live until the product ships and will continue to return an error until then.

Comment by Paul Davies [ 26/Jan/11 07:42 PM ]

Assigned to owner of admin_gui for fixing.

Comment by Anissa Lam [ 26/Jan/11 11:01 PM ]

How bad is its impact? (Severity)
Very severe. User will not be able to get to the documentation from admin conole.

How often does it happen? (Frequency)
Whenever user clicks the doc link in the common task page.

How much effort is required to fix it? (Cost)
1 hour

What is the risk of fixing it? (Risk)
changing this link is not risky, it is in the i18n string file.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No workaround.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes

Index: core/src/main/resources/org/glassfish/admingui/core/Strings.properties
===================================================================
— core/src/main/resources/org/glassfish/admingui/core/Strings.properties (revision 44647)
+++ core/src/main/resources/org/glassfish/admingui/core/Strings.properties (working copy)
@@ -400,10 +400,11 @@

  1. change the doc link to the localized copy if there is any
    -commonTasks.doc.qstart=http://www.oracle.com/pls/topic/lookup?ctx=821-2432
    -commonTasks.doc.adminGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2416
    -commonTasks.doc.devGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2418
    -commonTasks.doc.deployGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2417
    +commonTasks.doc.qstart=http://www.oracle.com/pls/topic/lookup?ctx=821-2432&id=sjsaseeqsg
    +commonTasks.doc.adminGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2416&id=sjsaseeag
    +commonTasks.doc.devGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2418&id=sjsaseedg
    +commonTasks.doc.deployGuide=http://www.oracle.com/pls/topic/lookup?ctx=821-2417&id=sjsaseeadg
    +
  2. end Common Tasks keys

#common

Comment by Anissa Lam [ 27/Jan/11 08:50 AM ]

Committed revision 44741.
Revision: 44741
Author : anilam
Date : Jan 27, 2011 8:49:41 AM
GLASSFISH-15663. Fix the link to the unbundled doc on common task page.

Approve: Anissa
Reviewer: Paul Davies.

Comment by stephanj [ 01/Feb/11 12:32 AM ]

The glassfish install summary HTML file shows many links to http://docs.sun.com/doc/820-7690 which are broken.

Comment by scatari [ 01/Feb/11 08:51 AM ]

Paul,
Can u provide us with the updated URL for Install Guide(online)? Are we not setting redirects for these links?

Thanks

Comment by Anissa Lam [ 01/Feb/11 12:20 PM ]

This bug has been resolved, and not related to installation summary HTML file at all.
I have opened http://java.net/jira/browse/GLASSFISH-15782 for that.





[GLASSFISH-15655] Installer image includes "subscriptions" Created: 21/Jan/11  Updated: 28/Jan/11  Due: 28/Jan/11  Resolved: 28/Jan/11

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 3.1_b38
Fix Version/s: 3.1_b40

Type: Bug Priority: Major
Reporter: jclingan Assignee: scatari
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jclingan and scatari

 Description   

The rotating graphics during installation contain one particular graphic that needs to be updated. The graphic is titled "Subscriptions", and is an unfortunate holdover from Sun GlassFish Enterprise Server v3. The other change is "Enterprise Manager" to "GlassFish Server Control"

Updated Content:

Title: Commercial Support

  • 24 x 7 x 365 support
  • Patch access
  • GlassFish Server Control for improved performance and manageability
  • Includes support for HotSpot JVM and Oracle JRockit

Since the above needs to be changed, also change the slide titled "Need to find help?" with the following content:

Title: Production Ready

  • High availability clustering
  • Centralized administration
  • Web Server load balancing plugin
  • Built-in GlassFish Server provisioning


 Comments   
Comment by scatari [ 21/Jan/11 04:19 PM ]

This would require updates to the original image files(.png). Will follow up with the design team that provided the updates last time.

Comment by scatari [ 28/Jan/11 06:05 PM ]

Fixed 3.1 workspaces(both trunk and branch) with updated images to cover all bundles(Open source, Oracle Branded and SDKs).
Here is the SVN checkin info including the revision numbers.

Trunk


Sending src/GlassFishV3Preview/resources/view/jwsdp_5.png
Sending src/GlassFishV3Preview/resources/view/jwsdp_6.png
Sending src/GlassFishV3WebProfilePreview/resources/view/jwsdp_5.png
Sending src/GlassFishV3WebProfilePreview/resources/view/jwsdp_6.png
Transmitting file data ....
Committed revision 44780.

Sending src/GlassFishV3Preview/resources/view/jwsdp_5.png
Sending src/GlassFishV3Preview/resources/view/jwsdp_6.png
Sending src/GlassFishV3WebProfilePreview/resources/view/jwsdp_5.png
Sending src/GlassFishV3WebProfilePreview/resources/view/jwsdp_6.png
Transmitting file data ....
Committed revision 2148.

Sending src/JavaEESDK/resources/view/jwsdp_5.png
Sending src/JavaEESDK/resources/view/jwsdp_6.png
Sending src/JavaEESDKWebProfile/resources/view/jwsdp_5.png
Sending src/JavaEESDKWebProfile/resources/view/jwsdp_6.png
Sending src/JavaEESDKWebProfileWithJDK/resources/view/jwsdp_5.png
Sending src/JavaEESDKWebProfileWithJDK/resources/view/jwsdp_6.png
Sending src/JavaEESDKWithJDK/resources/view/jwsdp_5.png
Sending src/JavaEESDKWithJDK/resources/view/jwsdp_6.png
Transmitting file data ........
Committed revision 2149.

Branch
------
Sending src/GlassFishV3Preview/resources/view/jwsdp_5.png
Sending src/GlassFishV3Preview/resources/view/jwsdp_6.png
Sending src/GlassFishV3WebProfilePreview/resources/view/jwsdp_5.png
Sending src/GlassFishV3WebProfilePreview/resources/view/jwsdp_6.png
Transmitting file data ....
Committed revision 44781.

Sending src/GlassFishV3Preview/resources/view/jwsdp_5.png
Sending src/GlassFishV3Preview/resources/view/jwsdp_6.png
Sending src/GlassFishV3WebProfilePreview/resources/view/jwsdp_5.png
Sending src/GlassFishV3WebProfilePreview/resources/view/jwsdp_6.png
Transmitting file data ....
Committed revision 2151.

Sending installer/src/JavaEESDK/resources/view/jwsdp_5.png
Sending installer/src/JavaEESDK/resources/view/jwsdp_6.png
Sending installer/src/JavaEESDKWebProfile/resources/view/jwsdp_5.png
Sending installer/src/JavaEESDKWebProfile/resources/view/jwsdp_6.png
Sending installer/src/JavaEESDKWebProfileWithJDK/resources/view/jwsdp_5.png
Sending installer/src/JavaEESDKWebProfileWithJDK/resources/view/jwsdp_6.png
Sending installer/src/JavaEESDKWithJDK/resources/view/jwsdp_5.png
Sending installer/src/JavaEESDKWithJDK/resources/view/jwsdp_6.png
Transmitting file data ........
Committed revision 2150.





[GLASSFISH-15743] Admin GUI crashes when cookies are blocked Created: 28/Jan/11  Updated: 28/Jan/11  Resolved: 28/Jan/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: v3.0.1
Fix Version/s: 3.1_b40

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

Firefox 3.6.13, Mac OS, Java 1.6.0_22


Tags:
Participants: Anissa Lam and mike_baranczak

 Description   

I went to http://localhost:4848/ and I got a completely un-helpful error message (stack trace from the log is below). I finally figured out what the cause was: I accidentally set Firefox to block cookies from localhost.

I obviously don't expect the admin app to function without cookies, but it would be nice if it could fail cleanly and tell the user what the problem is.

WARNING: StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:486)
at com.sun.faces.context.ExternalContextImpl.responseSendError(ExternalContextImpl.java:831)
at com.sun.faces.application.view.MultiViewHandler.send404Error(MultiViewHandler.java:666)
at com.sun.faces.application.view.MultiViewHandler.derivePhysicalViewId(MultiViewHandler.java:496)
at com.sun.faces.application.view.MultiViewHandler.createView(MultiViewHandler.java:160)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:221)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:253)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:680)



 Comments   
Comment by Anissa Lam [ 28/Jan/11 04:27 PM ]

I am running on Mac 10.5.8,

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-9M3263)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)

Google Chrome: 8.0.552.237
Firefox 3.6.13
Safari 5.0.3

I have tried on all three browser above. remove all cookie, disable cookie, restart server and launch GUI.
server.log says console is loaded.

[#|2011-01-28T16:20:13.934-0800|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=85;_ThreadName=Thread-39;|CORE10010: Loading application __admingui done in 25,236 ms|#]

[#|2011-01-28T16:20:13.936-0800|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=85;_ThreadName=Thread-39;|The Admin Console application is loaded.|#]

Browser tries to go to login screen, but cannot show it and getting blank screen instead.
I didn't see any stack trace.

Since there is no more stack trace that you mention in 3.1, I am marking this as resolved in 3.1





[GLASSFISH-15727] osgi-cache/felix dir name change Created: 27/Jan/11  Updated: 28/Jan/11  Resolved: 28/Jan/11

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: None
Fix Version/s: 3.1_b40

Type: Bug Priority: Major
Reporter: Nazrul Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved
Participants: Nazrul and Sanjeeb Sahoo

 Description   

GlassFish 3.1 recent build inadvertantly renamed osgi-cache/Felix. It used to be osgi-cache/felix in 3.0.1. This also breaks the directory naming standard used in rest of GlassFish (used lower case).



 Comments   
Comment by Sanjeeb Sahoo [ 27/Jan/11 08:56 PM ]

It's not a recent change - the name was changed 6-7 months ago... Will revert it back soon. Can you approve the bug?

Comment by Nazrul [ 27/Jan/11 09:05 PM ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Introduces an incompatibility

How often does it happen? (Frequency)
Always.

How much effort is required to fix it? (Cost)
Low

What is the risk of fixing it? (Risk)
Low

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
N/A

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
N/A

Comment by Sanjeeb Sahoo [ 28/Jan/11 01:05 AM ]

Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
Transmitting file data ..
Committed revision 44769.

Comment by Sanjeeb Sahoo [ 28/Jan/11 01:58 AM ]

Forward ported to trunk:

Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
Transmitting file data ..
Committed revision 44770.





[GLASSFISH-15726] appclient fails on Windows systems using MKS toolkit with java.lang.ClassNotFoundException: org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader Created: 27/Jan/11  Updated: 27/Jan/11  Resolved: 27/Jan/11

Status: Closed
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1_b39
Fix Version/s: 3.1_b40

Type: Bug Priority: Critical
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows running MKS toolkit


Tags: 3_1-approved
Participants: Tim Quinn

 Description   

Running the appclient script on a Windows system running the MKS toolkit fails with a stack trace beginning with this:

java.lang.Error: java.lang.ClassNotFoundException: org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1357)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1320)

The problem is that Java indicates that the CLIBootstrap class (which builds the java command to actually launch the ACC) is in a Windows environment, and therefore CLIBootstrap generates the java command using the semi-colon for the path separator. An earlier change dealt with this problem with Windows/cygwin systems, but does not handle the Windows/MKS case. As a result, the generated java command uses semi-colons for path separators but the MKS shell expects to see colons for that, and semi-colons as command separators.



 Comments   
Comment by Tim Quinn [ 27/Jan/11 07:27 PM ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Is a regression of functionality or performance available in a prior release
  • Likely to generate a customer support call

How often does it happen? (Frequency)
when a user runs the appclient command on a Windows system from an MKS shell

How much effort is required to fix it? (Cost)
minimal - I have a fix in my workspace already

What is the risk of fixing it? (Risk)
low to moderate - the appclient script is used not only on Windows/MKS and Windows/cygwin systems but also on non-Windows systems. I have already tested the fix on Windows/MKS and Mac OS X as an example of a non-Windows environment. I still need to test on Windows/cygwin.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
There is not a practical workaround. Users could avoid invoking appclient under MKS but that would defeat the purpose of having MKS installed - typically to provide a more uniform environment across multiple platforms.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

Comment by Tim Quinn [ 27/Jan/11 09:57 PM ]

Fixes checked in for the 3.1 branch and the trunk.

Branch check-in:

Project: glassfish
Repository: svn
Revision: 44766
Author: tjquinn
Date: 2011-01-28 05:54:29 UTC
Link:

Log Message:
------------
Fix for 15726

Similarly to cygwin, MKS on Windows expects the path separator to be the Unix-style colon separator. Java, left alone, though, will report the semi-colon as the path separator on Windows even if run under MKS. These changes cause the appclient script (non-Windows version only, which is used by MKS and cygwin shells as well as Unix shells) to set a property which indicates (basically) that a Unix-style invocation is in progress. This way, CLIBootstrap can use the suitable path separator.

Approved: Nazrul
Reviewed: Chris
Tests: appclient tests on Mac OS X, Windows/cygwin, Windows/MKS

Revisions:
----------
44766

Modified Paths:
---------------
branches/3.1/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java
branches/3.1/appclient/client/appclient-scripts/src/main/resources/glassfish/bin/appclient

Trunk check-in:

Project: glassfish
Repository: svn
Revision: 44767
Author: tjquinn
Date: 2011-01-28 05:55:52 UTC
Link:

Log Message:
------------
Fix for 15726

Similarly to cygwin, MKS on Windows expects the path separator to be the Unix-style colon separator. Java, left alone, though, will report the semi-colon as the path separator on Windows even if run under MKS. These changes cause the appclient script (non-Windows version only, which is used by MKS and cygwin shells as well as Unix shells) to set a property which indicates (basically) that a Unix-style invocation is in progress. This way, CLIBootstrap can use the suitable path separator.

Approved: Nazrul
Reviewed: Chris
Tests: appclient tests on Mac OS X, Windows/cygwin, Windows/MKS

Revisions:
----------
44767

Modified Paths:
---------------
trunk/v3/appclient/client/appclient-scripts/src/main/resources/glassfish/bin/appclient
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java





[GLASSFISH-15674] Update RC install image configurations to their final state Created: 24/Jan/11  Updated: 27/Jan/11  Resolved: 27/Jan/11

Status: Resolved
Project: glassfish
Component/s: update_center
Affects Version/s: 3.1_b38
Fix Version/s: 3.1_b40

Type: Bug Priority: Critical
Reporter: Snjezana Sevo-Zenzerovic Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved
Participants: Chris Kasso and Snjezana Sevo-Zenzerovic

 Description   

Install image configurations for all 3.1 distributions need to be updated to point to final set of preconfigure update center publishers and preferred publisher needs to be set to appropriate stable or release publisher.

This needs to happen on dedicated RC branch, trunk workspace needs to be left as-is for ongoing 3.2 work.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 24/Jan/11 04:10 PM ]

How bad is its impact? (Severity)

  • Required for correct update functionality of 3.1 FCS product distribution. Needs to happen late in the release cycle since appropriate FCS configuration is significantly different from pre-FCS one.

How often does it happen? (Frequency)

  • Always.

How much effort is required to fix it? (Cost)

  • Moderate effort.

What is the risk of fixing it? (Risk)

  • Minimal - same or similar set of changes has been used in two previous 3.x releases.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • No convenient workaround.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • No.
Comment by Chris Kasso [ 24/Jan/11 04:24 PM ]

Approved for 3.1

Comment by Snjezana Sevo-Zenzerovic [ 27/Jan/11 04:34 PM ]

Install image configuration changes have been checked in into 3.1 branch.





[GLASSFISH-15714] synchronous replication does not wait for wait for acknowledgement Created: 27/Jan/11  Updated: 27/Jan/11  Resolved: 27/Jan/11

Status: Resolved
Project: glassfish
Component/s: failover
Affects Version/s: 3.1_b39
Fix Version/s: 3.1_b40

Type: Bug Priority: Critical
Reporter: Mahesh Kannan Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved
Participants: Chris Kasso and Mahesh Kannan

 Description   

Currently, if I deploy an application with --asyncreplication=false, the response is sent back to the client before ACK is received from the replica instance. To make synchronous replication work properly, the response must be sent only after ACK is received



 Comments   
Comment by Mahesh Kannan [ 27/Jan/11 09:55 AM ]

1. How bad is its impact? (Severity)
Quite bad. Synchronous replication is broken

2. How often does it happen? (Frequency)
All the time when apps are deployed with --asyncreplication=false

3. How much effort is required to fix it? (Cost)
Small and The fix is available and reviewed.

4. What is the risk of fixing it? (Risk)
Small. It will not break our DFT tests since they use asyncreplication=true

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
No.

Diffs reviewed by Joe Fialli

svn diff
Index: src/main/java/org/shoal/ha/cache/impl/store/ReplicatedDataStore.java
===================================================================
— src/main/java/org/shoal/ha/cache/impl/store/ReplicatedDataStore.java (revision 1473)
+++ src/main/java/org/shoal/ha/cache/impl/store/ReplicatedDataStore.java (working copy)
@@ -156,9 +156,7 @@
Class<V> vClazz = dsc.getValueClazz();
DataStoreEntryUpdater<K, V> dseUpdater = null;

  • if (dsc.isDoSynchronousReplication()) { - dseUpdater = new SimpleDataStoreEntryUpdater(); - } else if (SimpleMetadata.class.isAssignableFrom(vClazz)) {
    + if (SimpleMetadata.class.isAssignableFrom(vClazz)) { dseUpdater = new SimpleStoreableDataStoreEntryUpdater(); } else if (Storeable.class.isAssignableFrom(vClazz)) {
    dseUpdater = new StoreableDataStoreEntryUpdater();
    Index: src/main/java/org/shoal/ha/cache/impl/command/CommandManager.java
    ===================================================================
      • src/main/java/org/shoal/ha/cache/impl/command/CommandManager.java (revision 1473)
        +++ src/main/java/org/shoal/ha/cache/impl/command/CommandManager.java (working copy)
        @@ -120,9 +120,9 @@
        if (forward)
        Unknown macro: { try { head.onTransmit(cmd, initiator); - //cmd.onSuccess(); + cmd.onSuccess(); } catch (DataStoreException dseEx) { - //cmd.onError(dseEx); + cmd.onFailure(); } }
        else {
        tail.onReceive(cmd, initiator);
        Index: src/main/java/org/shoal/ha/cache/impl/interceptor/ReplicationFramePayloadCommand.java
        ===================================================================
      • src/main/java/org/shoal/ha/cache/impl/interceptor/ReplicationFramePayloadCommand.java (revision 1473)
        +++ src/main/java/org/shoal/ha/cache/impl/interceptor/ReplicationFramePayloadCommand.java (working copy)
        @@ -42,14 +42,10 @@

import org.glassfish.ha.store.util.KeyTransformer;
import org.shoal.ha.cache.api.DataStoreException;
-import org.shoal.ha.cache.api.ObjectInputStreamWithLoader;
import org.shoal.ha.cache.api.ShoalCacheLoggerConstants;
import org.shoal.ha.cache.impl.command.Command;
import org.shoal.ha.cache.impl.command.ReplicationCommandOpcode;
-import org.shoal.ha.cache.impl.util.ReplicationInputStream;
-import org.shoal.ha.cache.impl.util.ReplicationOutputStream;

-import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
@@ -62,8 +58,7 @@
/**

  • @author Mahesh Kannan
    */
    -public class
  • ReplicationFramePayloadCommand<K, V>
    +public class ReplicationFramePayloadCommand<K, V>
    extends Command { private transient static final Logger _logger = @@ -179,19 +174,16 @@ getCommandManager().executeCommand(cmd, false, initiator); }

+ int executedRemoveCount = 0;
if (removedKeys != null) {
for (K k : removedKeys) { - dsc.getReplicaStore().remove(k); + dsc.getReplicaStore().remove(k); + executedRemoveCount++; }

  • }
  • }
  • @Override
  • public void onSuccess() {
  • int sz = commands.size();
  • for (int i = 0; i < sz; i++) {
  • Command cmd = commands.get;
  • cmd.onSuccess();
    + if (dsc.getDataStoreMBean() != null) { + dsc.getDataStoreMBean().updateExecutedRemoveCount(executedRemoveCount); + }
    }
    }

Index: src/main/java/org/shoal/ha/cache/api/ReplicatedDataStoreStatsHolder.java
===================================================================
— src/main/java/org/shoal/ha/cache/api/ReplicatedDataStoreStatsHolder.java (revision 1473)
+++ src/main/java/org/shoal/ha/cache/api/ReplicatedDataStoreStatsHolder.java (working copy)
@@ -268,6 +268,10 @@
}

+ public int updateExecutedRemoveCount(int delta) { + return executedRemoveCount.addAndGet(delta); + }
+
//@Override
public String toString() {
return "ReplicatedDataStoreStatsHolder{" +

Comment by Chris Kasso [ 27/Jan/11 10:36 AM ]

Approved for 3.1.

Comment by Mahesh Kannan [ 27/Jan/11 12:03 PM ]

svn commit -m "Integrate 1.5.29 version. Fixes issue 15714. QL passed"
Sending packager/resources/pkg_conf.py
Sending pom.xml
Transmitting file data ..
Committed revision 44750.





[GLASSFISH-15716] appclient -help option shows usage output, not help output Created: 27/Jan/11  Updated: 27/Jan/11  Due: 27/Jan/11  Resolved: 27/Jan/11

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1_b39
Fix Version/s: 3.1_b40

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved
Participants: Tim Quinn

 Description   

Running

appclient -help

should show the help output but it shows the usage output.



 Comments   
Comment by Tim Quinn [ 27/Jan/11 11:33 AM ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:
regression of functionality or performance available in a prior release

How often does it happen? (Frequency)
any time user runs "appclient -help"

How much effort is required to fix it? (Cost)
minimal

What is the risk of fixing it? (Risk)
very low

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
no workaround

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

Comment by Tim Quinn [ 27/Jan/11 11:35 AM ]

Chris gave his approval to this in separate e-mail. I'm recording that myself to save him the step.

Comment by Tim Quinn [ 27/Jan/11 11:52 AM ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 44748
Author: tjquinn
Date: 2011-01-27 19:51:34 UTC
Link:

Log Message:
------------
Fix for 15716

appclient -help displays the usage output, not the much more complete help output. This is because the code checks to make sure the user specifies a main class or a client JAR; if not, it automatically acts as if the user entered "-usage" instead. But that logic failed to account for cases in which the user specified -help (or -usage for that matter). And because the ACC checked for "-usage" before "-help" it would display the usage text instead.

These changes fix that.

Approved: Chris
Reviewed: Hong
Tests: updated appclient devtests

Revisions:
----------
44748

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java





[GLASSFISH-15696] ACC does not correctly handle multiple values for appclient -targetserver option Created: 26/Jan/11  Updated: 26/Jan/11  Due: 27/Jan/11  Resolved: 26/Jan/11

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1_b38
Fix Version/s: 3.1_b40

Type: Bug Priority: Critical
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved
Participants: Chris Kasso and Tim Quinn

 Description   

The appclient -targetserver option is intended to - and is documented to - accept multiple values as a comma-separated list.

Currently, the parsing of the agent argument for a multi-valued option does not work; only the first value is used.

How bad is its impact? (Severity)
regression

How often does it happen? (Frequency)
only if the user specifies multiple values for the -targetserver option

How much effort is required to fix it? (Cost)
an hour or two

What is the risk of fixing it? (Risk)
low

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Users can also specify multiple target servers by editing the sun-acc.xml config file (the -targetserver option was intended to allow users an easy way to specify what server(s) to connect to withOUT editing that config file) or by explicitly defining com.sun.appserv.iiop.endpoints on the appclient command line.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
yes



 Comments   
Comment by Tim Quinn [ 26/Jan/11 02:42 PM ]

In private e-mail, Ken C. correctly points out that the failure mode if a user specifies multiple -targetserver values is non-obvious. From Ken's e-mail:

"My only concern with deferring this fix is that the behavior of the system when the failure happens is
(currently at least) somewhat obscure: ORBInitialHost gets set to a cluster machine, which causes the client ORB initialization to fail. This may be an ORB bug, but it's quite confusing (it took me a couple of hours to run the problem down)."

Comment by Chris Kasso [ 26/Jan/11 03:56 PM ]

Approved for RC1. Integrate by COB Jan 27th.

Comment by Tim Quinn [ 26/Jan/11 11:14 PM ]

Fix checked in.

epository: svn
Revision: 44731
Author: tjquinn
Date: 2011-01-27 07:12:30 UTC
Link:

Log Message:
------------
Fix for 15696

CLIBootstrap encloses all agent argument values in double quotes before adding them to the generated java command which launches the app client container. But Unix-style shells consume the double quotes so they are gone by the time the agent argument string is available to the ACC. This causes problems if the user specifies more than one IIOP endpoint, separated by commas, as the -targetserver value.

These changes work around this problem by, in CLIBootstrap, encoding any comma in an agent argument as a special string
and, in AgentArguments, decoding the special string back into a comma.

Approved: Chris
Reviewed: Ken
Tests: QL, explicit tests with -targetserver set to multiple endpoints

Revisions:
----------
44731

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/acc/AgentArguments.java
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java





Generated at Thu Apr 24 07:55:01 UTC 2014 using JIRA 4.0.2#472.