Chapter 3 Known Issues and Limitations

The following sections describe the following kinds of issues related to Java ES 7:

• Issues relating to special situations when installing the products in Java ES 7

• Issues relating to special situations when upgrading to Java ES 7 from previous versions of Java ES

• Issues relating to the interoperation of two or more products in Java ES 7

• High priority issues that pertain to a product in Java ES 7

For quick reference, the following is a list of the issues described in the remainder of this chapter:

• (4756/4809) Portal Server 7.1u2 cohabitation issue on single node

• (5509) OpenSSO 8.0U1P1: redeployment fails with LifecycleException: java.lang.StackOverflowError

• (5571) OpenSSO 8.0 Upgrade: After ssoupgrade, Web Server is throwing errors

• (5634) ssoadm get-svrcfg-xml doesn't work if Opensso deployed in a GF 2.1 cluster w/ site

• (5696) Java ES 7: patch OpenSSO 8.0 by patch 141655-02 fails

• (20404) Directory Server and Identity Manager: LDAP group membership is not maintained when user account ID is changed in Identity Server

• (6358422/2183559) Appserver 7.1/8.1 EE: web server LB proxy plug-in should properly support keep-alive connections

• (6762401) Web Space Server Portal is not rendered properly through Reverse Proxy with Policy Agent (2.2, 3.0)

• (6808492) GF 2.1 CLI undeploy attempt fails and causes all future CLI commands to fail

• (6818829) JES6: GF2.1: can NOT log out from admin GF page

• (6819380) GlassFish Enterprise Server and Identity Manager: while upgrading to GlassFish Enterprise Server, Identity Manager idm.war file cannot be redeployed

• (6834364) Web Server 7 generates core dump when shut down if SUN LoadBalancer lbplugin is installed

• (6851521) GF2.1.1: GF upgrade script cannot deploy PS and/or IM

• (6881146) GlassFish installer (LB plugin installation) does not recognize valid Web Server instance directory

• (6882150) Web Space Server 10.0u6: com.liferay.util.EncryptorException thrown after update from 10.0

• (6882644) Java ES 7: Deployment of WSS war files failed if GF & WSS are installed from separated file based distributions

• (6883003) Web Application unable to find .wsdl file when deployed in two-machine GlassFish Cluster

• (6887791) JCAPS6u2: JSR-168 Portlets built in NetBeans are not transferable to another host (WSDL URL problem)

• (6889609/6889627) Web Server 7.0 NetBeans plugin does not add server if Web Server instance is not in Web Server install dir

• (6889664) Web Server 7.0 NetBeans plugin does not support JSF web applications

• (6891038) LoadBalancer plugin installer does not update virtual host obj.conf file during installation

• (6891737) Web Space servlet context "/" is blocking all other applications to be deployed on the same AS/GF

• (6893680) Web Space configured with OpenSSO: Change password in Web Space takes no effect

• (6903954) Java ES 7: login into a standalone Web Space Server 10u6 deployed on GF 2.1.1 results in a blank page

Further details and updates about many of these issues can be found at http://sunsolve.sun.com, http://bugs.sun.com, or http://java.net.

(4756/4809) Portal Server 7.1u2 cohabitation issue on single node

• Description

  After migrating from Access Manager 7.1.1 to OpenSSO 8.0, Portal Server 7.1u2 works properly when deployed on a separate node, but does not work if Portal Server and Access Manager are deployed on the same node. Portal Server fails to properly initialize, and the following error is shown in the server log:

  [#|2009-03-23T19:06:37.004+0100|SEVERE|sun-appserver2.1|javax.enterprise.system. container.web|_ThreadID=10;_ThreadName=main;_RequestID=00e6500a-e66c-42f4-9f06-6 afdace1a2d8;|WebModule[/surveys]PWC1275: Exception sending context initialized e vent to listener instance of class com.sun.faces.config.ConfigureListener java.lang.NoClassDefFoundError: com/iplanet/sso/SSOException

  The problem is that OpenSSO Enterprise and the AM SDK component of Access Manager cannot coexist in the same web container (Application Server/GlassFish), and Portal Server requires the AM SDK component.

  See the following URLs for more information about this bug:

  • 4756

  • 4809

• Solution

  OpenSSO does not support the package-based AM SDK. There is not a direct upgrade path for AM SDK-based installations. The recommended workaround is as follows:

  1. Leave Portal Server/AM SDK running on Application Server 8.2

  2. Install new GlassFish Enterprise Server v2.1 and deploy OpenSSO with /amserver to this GlassFish instance pointing to same Directory Server Enterprise Edition as Access Manager 7.1.

  3. Reconfigure Portal Server/AM SDK to point to OpenSSO on a different port.

(5509) OpenSSO 8.0U1P1: redeployment fails with LifecycleException: java.lang.StackOverflowError

• Description

  The issue can be observed after the following sequence of upgrade steps required to get from Access Manager 7.1 to 8.0U1P1 as described in the relevant documentation, Upgrading to OpenSSO Enterprise 8.0 in Sun OpenSSO Enterprise 8.0 Upgrade Guide:

  1. Undeploy AM7.1.

  2. Run the ssopre80upgrade script.

  3. Deploy OpenSSO 8.0 Enterprise.

  4. Configure the deployment against existing datastore (DSEE 6.3.1 in this case)

  5. Run the ssoupgrade script.

  6. Verify OpenSSO is working (optional).

  7. Use the ssopatch tool to prepare staging area for the 8.0U1P1.

  8. Prepare the WAR file from the staging area.

  Attempts to deploy the new amserver.war subsequently fail, and it appears there is an infinite loop during the application startup.

  See the report for 5509 for more information about this bug.

• Solution

  Problem has been addressed in latest OpenSSO Enterprise patch; for an upgrade, use OpenSSO Enterprise version 8.0 Update 1 Patch 4 or later.

(5571) OpenSSO 8.0 Upgrade: After ssoupgrade, Web Server is throwing errors

• Description

  When upgrading from Java ES 4 package-based (DS5.2, WS6.1, AM7.0, PS6.3.1) to Java ES 7 on Solaris 9u7 SPARC, an error is thrown when restarting after running ssoupgrade.

  See the report for 5571 for more information about this bug.

• Solution

  Problem has been addressed in latest OpenSSO Enterprise patch; for an upgrade, use OpenSSO Enterprise version 8.0 Update 1 Patch 4 or later.

(5634) ssoadm get-svrcfg-xml doesn't work if Opensso deployed in a GF 2.1 cluster w/ site

• Description

  The Web Space Server OpenSSO Add-On may not be able to retrieve an OpenSSO configuration on a GlassFish cluster node located beyond GlassFish LoadBalancer, which causes the OpenSSO Add-On to fail.

  See the report for 5634 for more information about this bug.

• Solution

  Do not deploy OpenSSO in a GlassFish Cluster, but instead use the OpenSSO Session failover capability.

(5696) Java ES 7: patch OpenSSO 8.0 by patch 141655-02 fails

• Description

  The issue occurs after following the sequence of steps for upgrading from Access Manager 7.1 to 8.0U1P2 provided in the product documentation, Upgrading to OpenSSO Enterprise 8.0 in Sun OpenSSO Enterprise 8.0 Upgrade Guide.

  See the report for 5696 for more information about this bug.

• Solution

  Verify the following:

  1. The ssoadm tools should be as described in the 8.0U1 patch installation instructions in “Running the updateschema Script.”

  2. -D"com.iplanet.am.naming.map.site.to.server=<lb-url>=<server-url>" should be added to the relevant ssoadm (ssoadm.bat) script before executing updateschema.sh.

(20404) Directory Server and Identity Manager: LDAP group membership is not maintained when user account ID is changed in Identity Server

• Description

  When a Directory Server 6.3.1 LDAP store is manageable in Identity Manager 8.0 through the Identity Manager LDAP resource adapter, changing a user's account ID in Identity Manager does not maintain LDAP group memberships for that user even if the Identity Manager accountId attribute is mapped to both the LDAP cn and uid attributes.

• Solution

  None.

(6358422/2183559) Appserver 7.1/8.1 EE: web server LB proxy plug-in should properly support keep-alive connections

• Description

  When the Sun Java System Application Server 7.1/8.1 load-balancing proxy plugin is used with Sun Web Server 7, requests are occasionally dropped under extreme loads. The error message seen in the logs is:

  RNTM3003: No server to service

• Solution

  There is no solution, but two possible workarounds:

  1. Disable the timeout setting on Web Server 7.

     web-server-install-dir/bin/wadm set-keep-alive-prop \ --user=admin --config=server-name timeout=-1

  2. Restart the Web Server.

(6762401) Web Space Server Portal is not rendered properly through Reverse Proxy with Policy Agent (2.2, 3.0)

• Description

  In some instances, HTTP responses are not forwarded correctly through the Reverse proxy feature of Web Server, resulting in the improper rendering of web pages in a web browser. This only occurs when there is both an SSO Policy Agent and a Reverse Proxy running at the same time on the Web Space Server.

• Solution

  Access through Reverse proxy is not supported. The preferred mode is to use the Secure Web Access (SWA) Add-On Secure and access Web Space Server with OpenSSO.

(6808492) GF 2.1 CLI undeploy attempt fails and causes all future CLI commands to fail

• Description

  Attempt to undeploy Sun Java™ Enterprise System 7 fails with message “Invalid user or password” and any command issued after this attempt fails with the same error message. At the same time it is no longer possible to log in via the GUI, which indicates that the authentication issue is not limited to the CLI. Restarting the domain clears the issue, but amserver is not undeployed, and another attempt to undeploy it causes the issue to reappear. If undeployment is attempted via GUI, the same authentication failure appears, but the web application is at least undeployed.

• Solution

  None. Restart the GlassFish domain to at least get back CLI and GUI functionality.

(6818829) JES6: GF2.1: can NOT log out from admin GF page

• Description

  After clicking the Logout button on the GlassFish Enterprise Server admin page, an empty confirmation alert is displayed. Clicking OK causes the console page to be reloaded, but the user is still not logged out.

  This issue affects Access Manager 7.x and GlassFish 2.1/2.1.1, and has been addressed in the latest Access Manager patch. The problem occurs when Application Server 8.x has been updated to GlassFish 2.x without also applying the latest Access Manager patch or upgrading to OpenSSO Enterprise Edition.

• Solution

  In the GlassFish Enterprise Server server.policy file, change the lines:

  permissiion java.security.AllPermission "MonitoringAuth.*"; permission java.security.AllPermission "MonitoringPolicy.*";

  to the following:

  permission javax.management.MBeanServerPermission "*"; permission javax.management.MBeanPermission "*", "*"; permission javax.management.MBeanTrustPermission "*"; permission java.io.FilePermission "//var/opt/SUNWmfwk/logs/*", "delete,write";

  Note that the path in the last line begins with two slashes (//). The first slash represents the installation directory of SUNWmfwk-rt. The default installation directory, /opt on Solaris or /opt/sun on Linux, equates to the single slash.

(6819380) GlassFish Enterprise Server and Identity Manager: while upgrading to GlassFish Enterprise Server, Identity Manager idm.war file cannot be redeployed

• Description

  When using the upgrade utility provided with GlassFish Enterprise Server to upgrade from Application Server 8.2, the upgrade log reports that the idm.war file could not be deployed.

• Solution

  Deploy the original idm.war file instead of the one that the upgrade utility modified and attempted to deploy. In a default installation of Identity Manager, the original war file is /opt/idm.war.

(6834364) Web Server 7 generates core dump when shut down if SUN LoadBalancer lbplugin is installed

• Description

  When Web Server 7.0 with lbplugin installed is shut down, a core file is generated. The core file contains something similar to the following:

  current thread: t@1 =>[1] __lwp_kill(0x0, 0x6, 0xfd5f3700, 0xfe822a00, 0xff36f338, 0x0), at 0xfd5c5bf0 [2] raise(0x6, 0x0, 0x20f04, 0xff34ba3c, 0xff36a000, 0xff36abdc), at 0xfd564bf4 [3] umem_do_abort(0x6, 0xffbff018, 0x6, 0x20e40, 0xff356ad8, 0x0), at 0xff349188 [4] umem_err_recoverable(0xff357b54, 0xa, 0x20d38, 0xfe8ae5d8, 0xff36d0e8, \ 0xff357b5f), at 0xff34932c [5] process_free(0x282468, 0x1, 0x0, 0x3e3a1000, 0x1ec08, 0xfe8ae3fc), \ at 0xff34b504 [6] INTdaemon_dorestart(0x1, 0xff272ffd, 0xff2abc04, 0x862d58, 0xfcbd40e8, \ 0xff2a2c00), at 0xff0ffb84 [7] WebServer::Run(0x1, 0x0, 0x6, 0x88108, 0x3d, 0xff272ec9), at 0xff1a5d5c [8] main(0x9, 0xffbff47c, 0xffbff4a4, 0x21400, 0x0, 0xfd035000), at 0x10fd4

  This problem occurs with all Application Server 8.1, 8.2, and 9.x when run on Web Server 7.x, and is caused by a duplicate entry for .

  Init fn="load-modules" shlib="libj2eeplugin.so" shlib_flags="(global|now)" Init fn="init-passthrough" ##END LB Plugin Parameters Init fn="load-modules" shlib="libj2eeplugin.so" shlib_flags="(global|now)"

• Solution

  Remove the first of the duplicate references to libj2eeplugin.so in the Web Server magnus.conf file and then restart Web Server.

(6851521) GF2.1.1: GF upgrade script cannot deploy PS and/or IM

• Description

  The Sun GlassFish Enterprise Server 2.1.1 (Build 17 sges_ee-2_1_1-fcs-bin-b17-solaris-i586-03_jun_2009.bin) upgrade tool cannot migrate Portal Server 6.3.1 (JES4) applications from AS 8.1_02 (JES4).

  This issue can affect the process of upgrading from Java ES 4 to Java ES 7 when updating Application Server 8.1 to GlassFish, and Portal server 6.3.1 and/or Instant Messaging are also installed. This problem may also affect other older applications when upgrading to GlassFish 2.x

  The problem is caused by a design flaw in the GlassFish 2.x upgrade tool because it recreates the archive from exploded application bits during upgrade process. The jar signature then becomes invalid when the archive is recreated.

• Solution

  None. Either update the older applications before updating to GlassFish, or perform a new GlassFish installation rather than an upgrade installation, and then manually redeploy the older applications to GlassFish.

(6881146) GlassFish installer (LB plugin installation) does not recognize valid Web Server instance directory

• Description

  Using GlassFish v2.1 file-based version, when attempting to install the Load Balancer Plugin using the GlasFish installer, the installer does not accept a Web Server instance that is created in different location then <Web-Server-install-dir>/https-<hostname>. Installation halts with an invalid directory error.

  By default, the Web Server 7.0 package that came with Java ES 5 and Java ES 5 U1 creates its instance in Sun Java™ Enterprise System 7. If you use this installation directory for the LoadBalancer plugin, the installation will fail.

• Solution

  Create symbolic link from Web Server instance directory to Web Server install directory so installer will recognize instance location; for example:

  ln -s /var/opt/SUNWwbsvr7/https-<hostname>.<domain> /opt/SUNWwbsvr7/https-<hostname>.<domain>

(6882150) Web Space Server 10.0u6: com.liferay.util.EncryptorException thrown after update from 10.0

• Description

  After upgrading from Web Space Server 10.0 to 10.0u6, the following exception can be observed in the GlassFish server.log:

  [#|2009-09-15T11:45:19.453+0000|INFO|sun-appserver2.1| \ javax.enterprise.system.stream.out|_ThreadID=23; \ _ThreadName=httpSSLWorkerThread-81-1;|11:45:19,448 \ ERROR [IncludeTag:165] com.liferay.util.EncryptorException: \ com.liferay.util.Encryptor \ Exception: java.security.ProviderException: update() failed at com.liferay.util.Encryptor.encryptUnencoded(Encryptor.java:205) at com.liferay.util.Encryptor.encrypt(Encryptor.java:174) at org.apache.jsp.html.common.themes.top_005fhead_jsp._jspService \ (top_005fhead_jsp.java from :1753) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)

• Solution

  Problem has been addressed in latest Web Space Server product patch; update Web Space Server to 10.0 Update 6 Patch 3 or later.

(6882644) Java ES 7: Deployment of WSS war files failed if GF & WSS are installed from separated file based distributions

• Description

  Deployment of Web Space Server WAR files (saw-web.war, glassfishregistrationportlet.war, ruon-web.war, dlmigrationportlet.war, and wsrp-portlet.war) fails if GlassFish and Web Space Server were installed from different file-based distributions.

• Solution

  Deploy the files manually by either using the Admin Console or copying the files to the domain autodeploy directory.

(6883003) Web Application unable to find .wsdl file when deployed in two-machine GlassFish Cluster

• Description

  Deployment of a Web Application .war file to GlassFish two—machine cluster is successful, but when attempting to access the application URL on Node2 (instance-TWO) where there is no DAS, a java.io.FileNotFoundException is thrown because the WSDL file cannot be found.

  The problem is that the DAS does not exist on Node2.

• Solution

  Create the directory hierarchy for domain1 (DAS), and then copy or create a symbolic link to the WSDL file in the location in which the Web application is looking for the file.

(6887791) JCAPS6u2: JSR-168 Portlets built in NetBeans are not transferable to another host (WSDL URL problem)

• Description

  When building and deploying a JSR168 Portlet that consumes a JCAPS Web Service to Web Space Server, portlet deployment fails with a WSDL file not found error. The problem is because the static code in CalculatorWSService.java is pointing to an absolute path on disk for the WSDL rather than a relative path within the WAR package.

• Solution

  There are two workarounds for this issue:

  1. Create the desired directory hierarchy on the Web Space Server host and copy the WSDL file there.

  2. Manually adjust the Wsimport options (CalculatorPortlet->Web Service References->CalculatorWSService->Edit Web Service Attributes) to specify the correct wsdlLocation; for example:

     wsdlLocation=http://jcaps-node1:8080/CalculatorApp/CalculatorWSService?wsdl

(6889609/6889627) Web Server 7.0 NetBeans plugin does not add server if Web Server instance is not in Web Server install dir

• Description

  Adding a Web Server 7.0 installation to NetBeans 6.5.1 produces an error when the Web Server instance being added is in a different directory than the main Web Server installation location; for example:

  • Web Server instance:

    /var/opt/SUNWwbsrv7/https-<node> /var/opt/SUNWwbsrv7/admin-server

  • Web Server installation directory:

    /opt/SUNWwbsrv7

  The error message displayed is “Please choose a Valid Sun java System Web Server 7.0 installation.”

• Solution

  None. The Web Server plugin for NetBeans currently works only for standalone installations. It assumes that the Web Server installation directory and Web Server instance directory are the same, because the instance depends on the admin library. The plugin checks for the existence of several directories and files, including admin-server, config, and server.xml, among others. If not found, the plugin fails.

(6889664) Web Server 7.0 NetBeans plugin does not support JSF web applications

• Description

  Using Netbeans 6.5.1 and Sun Java System Web Server 7.0 plugin, after adding Web Server 7.0 to the NetBeans Servers tab, and then trying to deploy a JSF application to Web Server, there is an error resolving the javax.faces.FacesException package.

  The problem is that the jsf-impl.jar and jsf-api.jar are not being loaded by the plugin. The Web Server plugin for NetBeans does not support the loading of these classes.

• Solution

  Choose GlassFish v2 as the target server in the NetBeans Servers tab and build the application against GlassFish rather than Web Server. After building the application, do not deploy it through NetBeans, but instead deploy it manually to Web Server using the wadm CLI or the Web Server admin console.

(6891038) LoadBalancer plugin installer does not update virtual host obj.conf file during installation

• Description

  In some circumstances, when the LoadBalancer plugin is properly installed on Web Server 7 and the loadbalancer.xml file generated, the LoadBalancer still does not initialize properly.

  For example, consider the following scenario:

  • A user performs a specific configuration on a Web Server virtual host (for example, Web Server virtual server Log preferences) before installing the LoadBalancer plugin In this example, Web Server generates a new obj.conf file with a virtual host name: <ws-virtual-host-name>-obj.conf.

  • During LoadBalancer plugin installation, the process automatically updates various Web Server configuration files (server.xml, magnus.conf, obj.conf), but does not update <ws-virtual-host-name>-obj.conf.

  The problem in this scenario is that the <ws-virtual-host-name>-obj.conf file takes precedence over the other configuration files in the Web Server startup sequence, and when the required lbplugin entries are missing, the LoadBalancer does not fully initialize even though no error message is displayed.

• Solution

  Manually add the following entries to the <ws-virtual-host-name>-obj.conf file:

  1. Under the <Object name="default"> tag add the following on a single line:

     NameTrans fn="name-trans-passthrough" name="lbplugin" \ config-file="/opt/SUNWwbsvr7/https-<ws_config_name>/config/loadbalancer.xml"

  2. At the bottom of the file, append the following:

     <Object name="lbplugin"> PathCheck fn="deny-existence" path="*/WEB-INF/*" ObjectType fn="force-type" type="magnus-internal/lbplugin" Service type="magnus-internal/lbplugin" fn="service-passthrough" Error reason="Bad Gateway" fn="send-error" uri="$docroot/badgateway.html" </Object> <Object ppath="*lbconfigupdate*"> PathCheck fn="get-client-cert" dorequest="1" require="1" </Object> <Object ppath="*lbgetmonitordata*"> PathCheck fn="get-client-cert" dorequest="1" require="1" </Object>

  After making these changes, restart the LoadBalancer.

(6891737) Web Space servlet context "/" is blocking all other applications to be deployed on the same AS/GF

• Description

  After deploying Web Space Server into a GlassFish (v2.1) domain in which other applications are already installed (for example, OpenSSO 8, Access Manager Server 7, or some sample application), those applications can no longer be accessed.

  The problem is that Web Space Server takes over the servlet context root (/), which causes all web references to be redirected through the portal infrastructure. Note that this problem does not occur for applications that are deployed to GlassFish after Web Space Server; that is, the order in which the applications are deployed relative to Web Space Server is significant.

• Solution

  The default context root, “/”, can be changed by specifying a different context root during deployment; for example:

  asadmin deploy -contextroot /foo

  Note that if you do this, you also must set the portal.ctx configuration parameter in portal-ext.properties to match. For more information, see Portal Context in Sun GlassFish Web Space Server 10.0 Administration Guide.

(6893680) Web Space configured with OpenSSO: Change password in Web Space takes no effect

• Description

  When Web Space Server is configured to authenticate users through OpenSSO, changing a Web Space Server user password through the Web Space My Account portlet does not propagate the changed password to the OpenSSO server.

  The My Account portlet comes from Liferay, and all authentication mechanisms provided by Liferay have the same issue. It is expected that if anything other than default authentication mechanism is used, changing the password field in control panel will not have an effect. This is a known limitation with using external SSO solutions in general; user attributes that are controlled by OpenSSO (user name, password, and so forth) should not be editable when an external SSO solution is enabled, or it should redirect to the SSO server's UI.

• Solution

  Modify user attributes using the OpenSSO server interface rather than the Web Space Server My Account portlet.

(6903954) Java ES 7: login into a standalone Web Space Server 10u6 deployed on GF 2.1.1 results in a blank page

• Description

  Unable to login into a standalone Web Space Server 10 U6 instance deployed on GlassFish 2.1.1; login results in a blank page.

• Solution

  Problem has been addressed in latest Web Space Server patch; update Web Space Server to version 10.0 Update 6 Patch 3 or later.