[GLASSFISH-15542] The install program crash when execute the bundle named ogs-3.1-b37-unix-ml.sh in ja_JP.UTF-8 locale Created: 12/Jan/11  Updated: 16/May/11  Due: 18/Jan/11  Resolved: 13/Jan/11

Status: Closed
Project: glassfish
Component/s: installation
Affects Version/s: 3.1_b36
Fix Version/s: 3.1_b38

Type: Bug Priority: Critical
Reporter: sunny-gui Assignee: gmurr
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: OEL 5, SUSE 11


Attachments: JPEG File install_crash_ja.jpg    

 Description   

The install program crash when execute the bundle named ogs-3.1-b37-unix-ml.sh in ja_JP.UTF-8 locale.

JAVA version: 1.6.0_20
Build version: 3.1_b37

To reproduce:
1. set locale as ja_JP.UTF-8
2. execute bundle ogs-3.1-b37-unix-ml.sh.

The install GUI will be quickly displayed and then the program crashed with error. It only happens in ja locale, it is okay in other 8 locales and en locale. Please see attached screen shot for your reference.



 Comments   
Comment by gmurr [ 12/Jan/11 ]

this seem to be issue in the ja property file.

Comment by gmurr [ 12/Jan/11 ]

The translation of Welcome entry in pagesequence.properties is causing this issue. Will replace it with alternative translation

Comment by gmurr [ 13/Jan/11 ]

fixed the translation issue in pagesequence_ja.properties

Comment by sunny-gui [ 19/Jan/11 ]

Verified with the bundle ogs-3.1-b38-unix-ml.sh in OEL 5, it is still reproducible.

Comment by sunny-gui [ 24/Jan/11 ]

Verified and fixed in the bundle glassfish-3.1-b39-01_23_2011-unix-ml.sh in OEL 5.





[GLASSFISH-15570] there is unexpected character 'd' in the Installation Type Page Created: 14/Jan/11  Updated: 16/May/11  Resolved: 14/Jan/11

Status: Closed
Project: glassfish
Component/s: installation
Affects Version/s: 3.1_b36
Fix Version/s: 3.1_b38

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: gmurr
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: OEL 5


Attachments: JPEG File unexpect_character_d_zh_TW.jpg    

 Description   

there is unexpected character 'd' in the Installation Type Page during install GF.

Bundle: java_ee_sdk-6u2-b37-jdk-linux-ml.sh
Locale: zh_TW
Build: build 37

Launch the GF installer program with invoke bundle named java_ee_sdk-6u2-b37-jdk-linux-ml.sh in zh_TW locale. There is unexpected character 'd' in the Installation Type Page.

Please refer to attached screen shot for details.



 Comments   
Comment by scatari [ 14/Jan/11 ]

Assigning to L10N team. The english text has "4848 and...". Possibly the "d" is from mistranslation of "and".

Comment by gmurr [ 14/Jan/11 ]

removed the extra character from the translation





[GLASSFISH-15050] RuntimeException Thrown when Logger Settings/General Page is edited and Saved in a new config Created: 08/Dec/10  Updated: 21/Feb/11  Due: 18/Jan/11  Resolved: 12/Jan/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_b31
Fix Version/s: 3.1_b38

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

OS: Soalris Sparc 10
Browser: firefox 3.6


Attachments: JPEG File gui-showing-error.jpg    
Tags: 3_1-verified

 Description   

Build used : GF nightly dated 12/08

Create a new configuration by copying from default-config.
In the newconfig/Logger Settings/General Page, Edit some fields, and/or enable "Write to System log" checkbox, or" Log ot Console" checkbox and click "Save" button. See that in the console window, "java.lang.RuntimeException" is thrown.

This happens only in a new conffig. In the server-config the changes get saved successfully.

In the server.log, the below Exception is seen:

[#|2010-12-08T14:17:53.937-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=15;_ThreadName=Thread-1;|javax.faces.FacesException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'saveButton'.
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:89)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:395)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
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:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
@ at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'saveButton'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
... 33 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more



 Comments   
Comment by sirajg [ 08/Dec/10 ]

I cannot reproduce it with b31 or the current build. I created a new config, made modifications to the logger settings and clicked Save. I tried with a config associated with and instance and without an instance. It worked in both the cases. There was an issue in logging backend earlier which would have produced similar result. Don't have that issue number.

Closing as not reproducible. Reopen with more details if it is still reproiducible.

Comment by shaline [ 11/Jan/11 ]

This issue is existing on latest GF nightly builds dated b37-01-11-2011 on Windows, and Sparc platforms.
When we try to edit a instances config ( not the server-config), but a local or remote instances config's Logger settings/General page and click SAVE button, we see the java.lang.RuntimeException in the Console.
In the server.log the below NullPointerException is thrown:

[#|2011-01-11T16:27:19.186-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.syst
em.tools.admin.com.sun.enterprise.v3.admin|_ThreadID=38;_ThreadName=Thread-1;|Ex
ception in command execution : java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.enterprise.server.logging.commands.SetLogAttributes.execute(S
etLogAttributes.java:172)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunner
Impl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunner
Impl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunner
Impl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunn
erImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execut
e(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execut
e(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:
453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:22
0)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java
:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java
:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(Container
Mapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:8
18)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFil
ter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultPro
tocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java
:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextT
ask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.
java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadP
ool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool
.java:513)
at java.lang.Thread.run(Thread.java:662)

#]
Comment by Anissa Lam [ 11/Jan/11 ]

I can reproduce this consistently when trying to do a SAVE on the General tab of Logger Settings, where the config is that of a RUNNING server.
The server has to be running to see this exception.
However, GUI wasn't calling the restRequest() method with the correct parameter, so instead of showing the user the error from the backend, we throw the exception on screen.

I am going to fix the GUI code to ensure that if there is any error in backend, that the error will be shown correctly. (see attached screen which is after the change below). And then transfer the bug to logging.

How bad is its impact? (Severity)
GUI throws an exception on screen is not acceptable.

How often does it happen? (Frequency)
Everytime when doing a save in the logger settings General and Logger level screen, and there is any error reported by backend.

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

What is the risk of fixing it? (Risk)
almost no risk

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

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

svn diff

~/Awork/V3/v3/admingui 152) svn diff common
Index: common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java
===================================================================
— common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (revision 44400)
+++ common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (working copy)
@@ -134,7 +134,7 @@
props.put("id", oneRow.get("loggerName") + "=" + oneRow.get("level"));
props.put("target", config);
RestUtil.restRequest((String)GuiUtil.getSessionValue("REST_URL") + "/set-log-levels.json",

  • props, "POST", null, true);
    + props, "POST", handlerCtx, true, true);
    }

}
@@ -156,7 +156,7 @@
props.put("id", key + "='" + attrs.get(key) + "'");
props.put("target", config);
RestUtil.restRequest((String)GuiUtil.getSessionValue("REST_URL") + "/set-log-attributes.json",

  • props, "POST", null, true);
    + props, "POST", handlerCtx, true, true);
    }
    }
Comment by Anissa Lam [ 12/Jan/11 ]

While doing more testing, i see that the .jsf file called prepareSuccessfulMsg AFTER calling the handler. This overwrites any warning from the handler. So, I am moving that to before calling the handler.
We should always call prepareSuccessful before any handler. If there is any exception/failure in the handler, the sequence command will not continue and no need to worry that prepareSuccessful will be called.

We also break out of the for loop if there is any error in the request, instead of continue to set more attributes.
So, here is the new diff.

~/Awork/V3/v3/admingui/common 158) svn diff
Index: src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java
===================================================================
— src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (revision 44400)
+++ src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java (working copy)
@@ -1,7 +1,7 @@
/*

  • DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
    *
  • * Copyright (c) 2009-2010 Oracle and/or its affiliates. All rights reserved.
    + * Copyright (c) 2009-2011 Oracle and/or its affiliates. All rights reserved.
    *
  • The contents of this file are subject to the terms of either the GNU
  • General Public License Version 2 only ("GPL") or the Common Development
    @@ -130,11 +130,15 @@
    List<Map<String,Object>> allRows = (List<Map<String,Object>>) handlerCtx.getInputValue("allRows");
    String config = (String)handlerCtx.getInputValue("config");
    Map<String, Object> props = new HashMap();
  • for(Map<String, Object> oneRow : allRows){
  • props.put("id", oneRow.get("loggerName") + "=" + oneRow.get("level"));
  • props.put("target", config);
  • RestUtil.restRequest((String)GuiUtil.getSessionValue("REST_URL") + "/set-log-levels.json",
  • props, "POST", null, true);
    + try
    Unknown macro: {+ for(Map<String, Object> oneRow }

    catch(Exception ex)

    { + GuiUtil.handleException(handlerCtx, ex); }

    }
    @@ -152,11 +156,15 @@
    String[] attrNames = attrsInUI.split(",");
    String config = (String)handlerCtx.getInputValue("config");
    Map<String, Object> props = new HashMap();
    - for(String key : attrNames){
    - props.put("id", key + "='" + attrs.get(key) + "'");
    - props.put("target", config);
    - RestUtil.restRequest((String)GuiUtil.getSessionValue("REST_URL") + "/set-log-attributes.json",
    - props, "POST", null, true);
    + try{
    + for(String key : attrNames){ + props.put("id", key + "='" + attrs.get(key) + "'"); + props.put("target", config); + RestUtil.restRequest((String)GuiUtil.getSessionValue("REST_URL") + "/set-log-attributes.json", + props, "POST", null, false, true); + }
    + }catch (Exception ex){ + GuiUtil.handleException(handlerCtx, ex); }

    }

Index: src/main/resources/configuration/loggerLevelsButtons.jsf
===================================================================
— src/main/resources/configuration/loggerLevelsButtons.jsf (revision 44400)
+++ src/main/resources/configuration/loggerLevelsButtons.jsf (working copy)
@@ -47,8 +47,8 @@
<!command
getUIComponent(clientId="$pageSession

{tableRowGroupId}

", component=>$attribute

{tableRowGroup});
getAllSingleMapRows(TableRowGroup="${tableRowGroup}

" Rows=>$attribute

{allRows}

);
+ prepareSuccessfulMsg();
updateLoggerLevels(allRows="#

{requestScope.allRows}

" config="#

{pageSession.configName}");
- prepareSuccessfulMsg();
gf.redirect(page="#{request.contextPath}/common/configuration/loggerLevels.jsf?configName=#{pageSession.configName}

&alertType=$

{alertType}&alertSummary=${alertSummary}&alertDetail=${alertDetail}");
/>
</sun:button>
Index: src/main/resources/configuration/loggerGeneral.jsf
===================================================================
— src/main/resources/configuration/loggerGeneral.jsf (revision 44400)
+++ src/main/resources/configuration/loggerGeneral.jsf (working copy)
@@ -85,8 +85,8 @@
<sun:button id="saveButton" text="$resource{i18n.button.Save}"
onClick="if (guiValidate('#{reqMsg}','#{reqInt}','#{reqPort}')) {submitAndDisable(this, '$resource{i18n.button.Processing}');}; return false;" >
<!command
+ prepareSuccessfulMsg();
saveLoggingAttributes(attrs="#{pageSession.logAttributes}" attrsInUI="#{pageSession.attrsInUI}" config="#{pageSession.configName}");
- prepareSuccessfulMsg();
gf.redirect(page="#{request.contextPath}/common/configuration/loggerGeneral.jsf?configName=#{pageSession.configName}&alertType=${alertType}

&alertSummary=$

{alertSummary}

&alertDetail=$

{alertDetail}

");
/>
</sun:button>

Comment by sirajg [ 12/Jan/11 ]

Changes look good

Comment by Anissa Lam [ 12/Jan/11 ]

Fix checked in on 1/12.

Project: glassfish
Repository: svn
Revision: 44440
Author: anilam
Date: 2011-01-12 15:48:34 UTC
Link:

Log Message:
------------
Fix GLASSFISH-15050 . Ensure the error from logging backend will be displayed to user appropriately instead of throwing the exception on screen.

Approved: self-approve
Reviewer: Siraj.

Revisions:
----------
44440

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/resources/configuration/loggerLevelsButtons.jsf
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/LoggingHandlers.java
trunk/v3/admingui/common/src/main/resources/configuration/loggerGeneral.jsf
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java

Comment by Anissa Lam [ 12/Jan/11 ]

I don't mean to close this. Since the underlying issue is in logging. GUI is just fixed so that GUI will display the error from backend.
However those error shouldn't occur at all.

Comment by Anissa Lam [ 12/Jan/11 ]

Transferring to logging.
If the instance is not running, logger/loglevel setting can be changed.
But if the instance is running, we are seeing this error:

[#|2011-01-12T12:54:41.000-0800|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=27;_ThreadName=admin-thread-pool-4848(4);|Exception Occurred :An error occurred during replication FAILURE: Command set-log-attributes failed on server instance ST2: remote failure: java.lang.NullPointerException|#]

Comment by naman_mehta [ 12/Jan/11 ]

Hi anissa,
I recently fixed one issue(11th Jan) on the same line: http://java.net/jira/browse/GLASSFISH-15510

So looks like it's same one. I will verify the same and closing this issue. Is it fine?

Comment by naman_mehta [ 12/Jan/11 ]

I verified the issue by doing following steps.

1. Started Server
2. Created local instance in1
3. Created local instance in2
4. Started local instance in1.
5. Open admin console
6. Go to in1-config, Logger Settings, General. Updated value for two checkboxes and did save. It works fine.
7. Go to in2-config, Logger Settings, General. Updated value for two checkboxes and did save. It works fine.

So here, in1 is running and in2 is stopped but logger setting works fine in both condition. No exception in the GUI and back end.

Do I need to test other thing apart from the same? If no, can I close this issue?

Comment by naman_mehta [ 12/Jan/11 ]

Also verfied,

Create a new configuration by copying from default-config.
In the newconfig/Logger Settings/General Page, Edit some fields, and/or enable "Write to System log" checkbox, or" Log ot Console" checkbox and click "Save" button.

Works fine without any Exception.

Comment by naman_mehta [ 12/Jan/11 ]

Closing this issue as it is not reproducible on latest workspace.

Comment by Anissa Lam [ 12/Jan/11 ]

I was able to reproduce the issue consistently, until i update to the latest code under core/logging.
so, sounds like code checked in yesterday to fix the other logging bug fixes this issue also.
Shalini can verify this.

Comment by shaline [ 21/Feb/11 ]

Verified in promoted b43.





[GLASSFISH-15421] javax.net.ssl.SSLHandshakeException seen while loading Console after enable-secure-admin in windows. Created: 03/Jan/11  Updated: 21/Feb/11  Resolved: 11/Jan/11

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

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

OS: windows XP, and Windows 2008.
Browsers : IE 7, and firefox 3.6


Attachments: Java Source File AdminConsoleAuthModule.java     Java Source File RestUtil.java     Text File server.log    
Tags: 3_1-approved, 3_1-verified

 Description   

Installed the latest GF nightly build dated b36-01-03-2011 and used the installer bundles latest-ogs-windows.exe on Windows machines. JDK used is : jdk 1.6.0_23

Trying to access Console after enabling secure-admin. After accepting certificates, the Console takes a while to load, and in the meantime the server.log has the below Exceptions.
This is seen only in windows OS. I could reproduce on both XP and 2008 server using nightly build b36-01-03-2011

steps:

start domain1,
asadmin enable-secure-admin
restart domain1.

Access Console : http://localhost:4848
redirection happens to https://localhost:4848
Accept certificates.
Then console takes forever to load...

server.log has below Exception:

[#|2011-01-03T19:38:51.414-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=95;_ThreadName=Thread-1;|The
Admin Console application is loaded.|#]

[#|2011-01-03T19:38:54.304-0800|WARNING|oracle-glassfish3.1|javax.enterprise.sys
tem.container.web.com.sun.enterprise.web|_ThreadID=81;_ThreadName=Thread-1;|Appl
icationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw ex
ception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while at
tempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHa
ndlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHa
ndlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate
(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(Lay
outComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(L
ayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewH
andler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.jav
a:244)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.jav
a:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:395)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java
:1534)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDi
spatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(Applica
tionDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(Application
Dispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDi
spatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDis
patcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validat
eRequest(AdminConsoleAuthModule.java:195)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServ
erAuthContext.validateRequest(GFServerConfigProvider.java:1171)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1312)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAda
pter.java:1190)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.j
ava:623)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipel
ine.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESess
ionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.j
ava:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(Container
Mapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:8
18)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFil
ter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultPro
tocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java
:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextT
ask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.
java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadP
ool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool
.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handl
er.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHa
ndlers(LayoutElementBase.java:420)
... 44 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHa
ndshakeException: java.security.cert.CertificateException: No name matching loca
lhost found
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle
(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)

at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:45
9)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:642)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java
:176)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(Re
stApiHandlers.java:210)
... 50 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateEx
ception: No name matching localhost found
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1
649)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:235)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Clien
tHandshaker.java:1206)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHa
ndshaker.java:136)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:5
93)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.jav
a:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.j
ava:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SS
LSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketIm
pl.java:1165)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketIm
pl.java:1149)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:
434)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect
(AbstractDelegateHttpsURLConnection.java:166)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLCon
nection.java:1177)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379
)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Htt
psURLConnectionImpl.java:318)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invok
e(URLConnectionClientHandler.java:217)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle
(URLConnectionClientHandler.java:129)
... 57 more
Caused by: java.security.cert.CertificateException: No name matching localhost f
ound
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509T
rustManagerImpl.java:264)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(
X509TrustManagerImpl.java:250)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Clien
tHandshaker.java:1185)
... 71 more

#]


 Comments   
Comment by shaline [ 03/Jan/11 ]

Attached Sever.log

Comment by Anissa Lam [ 04/Jan/11 ]

Requesting help from Ludo.
According to Shaline, this only occurs on Window. If you need access to her machine, she can made that available.

Comment by shaline [ 04/Jan/11 ]

I tried the nightly dated 01/04-2011 on windows 7 and see the same issues as seen on XP, and windows 2008.

Comment by Mitesh Meswani [ 05/Jan/11 ]

The difference indeed is with using installer (ogs-windows.exe) vs. zip bundle. The installer creates domain using "asadmin create-domain" that results in different content for keystore.jks. The CN for certificates in keystore when using installer contains actual host name and it is "localhost" for certificate in keystore from zip bundle.

Here are shortened steps to reproduce the issue.

install glassfish (any way you want it, any OS you want it)
asadmin create-domain domainfoo
asadmin start-domain domainfoo
asadmin enable-secure-admin
asadmin stop-domain domainfoo
asadmin start-domain domainfoo

access admin console of domainfoo and the error manifests.

Comment by Tim Quinn [ 07/Jan/11 ]

There has been considerable e-mail traffic about this.

The current thinking (from Kumar) is that the admin console might have to specify the actual host name (rather than localhost) when it connect to the DAS for REST requests. That, or use a slightly different host name verifier.

As a result, I am transferring this back to Anissa.

Comment by Nazrul [ 07/Jan/11 ]

Getting help from Kumar. We need more specific instructions for console/REST teams.

Comment by kumara [ 07/Jan/11 ]

It looks like we are making REST calls over the wire even when we are coming back to same VM. Assuming that is the way it will be, shouldn't REST URL be formed by using the host obtained from request.getHost() from admin console. It is still possible that the certificate might have a different host name, so a more forgiving HostName Verifier for REST admin interface client (which will be admin GUI) is the best fix for this issue.

Comment by Anissa Lam [ 07/Jan/11 ]

I have been working on this for the last 2 days, trying out different scenario and experimenting with how to use the HostName Verifier. All in vein.
Basically, for the rest endpoint that GUI uses, it has to match EXACTLY the CN of the certificate. Otherwise, there will be the CertificateException. According to Kumar, HostName Verifier is the solution. I have tried using that, result in some other exception.

Here is the latest email i sent. That kind of summarize the situation.
I have also tried this with the latest code that Kumar mentioned he has checked in, without specifying SSLContext.getInstance(), in the HTTPSProperties, still the same exception.

On 1/6/11 11:00 PM, Kumar.Jayanti wrote:

> On 07/01/11 12:17 PM, Anissa Lam wrote:
> Hi Kumar,
>
> Thanks for looking into this and give input. The code and the stack trace that i showed you was NOT in any of the checkin code. It is just some experiment that Mitesh and I tried.
> I spent entire day today working on this, experimenting on different scenario. Mitesh gave more suggestion but at the end, I am back to square one. Since i have never worked on codes related to security before, I have a hard time understanding what needs to be done, including the suggestion you gave below.
> Let me summarize what I did today, and see if it makes sense to you.
>
> - Without adding any code relating for HostName Verifier, I see the CertificateException if the endpoint we use for REST doesn't match the CN of the certificate.
> case 1: default domain, CN=localhost, using this endpoint "https://dhcp-whq-twvpn-1-vpnpool-10-159-247-97:4848/management/domain/anonymous-user-enabled" will get the following exception
> Caused by: java.security.cert.CertificateException: No name matching dhcp-whq-twvpn-1-vpnpool-10-159-247-97.vpn.oracle.com found
> at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
> at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
> at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:264)
> at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:250)
> at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)

yes, when using HTTPS the hostname in the URL used to request the endpoint should match the CN of the certificate in glassfish server keystore's s1as alias. Otherwise you would see this exception.

>
> case 2: new domain created, certificate CN=dhcp-whq-twvpn-1-vpnpool-10-159-247-97 using this endpoint: http://localhost:4848/management/domain/anonymous-user-enabled will get the following exception
> Caused by: java.security.cert.CertificateException: No name matching localhost found
> at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
> at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
> at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:264)
> at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:250)
> at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
> ... 71 more
>
> So, even if i put in the logic to find the hostname and use that as the endpoint instead of hard coding "localhost", there will be case that it will not work. Sounds like the endpoint HAS to match the CN of the cert.
>

That's correct. You somehow need to know what is the CN of the server cert and use exactly that. Which sounds like a difficult problem.

But then setting a HostNameVerifier is the solution to this problem.

> I then call the following code:
> public static void initialize(Client client, String serverName){
> if (client == null)

{ > client = JERSEY_CLIENT; > }

> try

{ > HTTPSProperties httpsProperties = new HTTPSProperties(new BasicHostnameVerifier( serverName) , SSLContext.getInstance("TLS")); <======== I have tried SSLContext.getInstance("SSL"); SAME exception as below. > client.getProperties().put(HTTPSProperties.PROPERTY_HTTPS_PROPERTIES, httpsProperties); > }

catch(Exception ex)

{ > ex.printStackTrace(); > }

> }
>
you may not need the SSLContext.getInstance() call above. Have you tried setting this hostnameverifier as you have done and try with the very latest builds of GlassFish. I have checked in code yesterday night. ?

regards,
kumar

> private static class BasicHostnameVerifier implements HostnameVerifier {
> private final String host;
> public BasicHostnameVerifier(String host)

{ > if (host == null) > throw new IllegalArgumentException("null host"); > this.host = host; > }

> public boolean verify(String s, SSLSession sslSession)

{ > return host.equals(s); > }

> }
>
> This executed without issue, but then the next request GUI sent to REST will result in the following:
>
> Caused by: java.lang.IllegalStateException: SSLContextImpl is not initialized
> at com.sun.net.ssl.internal.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:145)
> at javax.net.ssl.SSLContext.getSocketFactory(SSLContext.java:260)
> at com.sun.jersey.client.urlconnection.HTTPSProperties.setConnection(HTTPSProperties.java:140)
> at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:166)
> at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
> ... 32 more
>
>
I am not sure what you mean by
>>
>> However the SSLContext that we initialize uses a KeyManager initialized using the "alias" specified by
>> -Dcom.sun.enterprise.security.httpsOutboundKeyAlias=YOUR_ALIAS

> As I have no experience with this area of code, something that seems trivial to you will not be for me.
> If you can help me modify the above code fragment to do what you think needs to be done, I really appreciate that. I do not know how to move forward now.
>
> thanks
> Anissa.

Comment by Tim Quinn [ 07/Jan/11 ]

Anissa,

I've spent time looking at the code that creates the domain to see exactly how it computes the CN for the certificate to see if there is an easy way to resolve this. There might not be an easy way that covers 100% of the cases, but there might be one for the vast majority of the cases.

During domain creation, KeystoreManager computes the CN this way:

1. If, on the create-domain command, the user specifies --keytooloptions CN=someValue, then use the specified value.

2. Otherwise, use the value returned from NetUtils.getCanonicalHostName().

I suspect very few users specify the CN on the create-domain command, so a simple fix for most cases would be for the admin console's host name verifier to accept either localhost or the value from NetUtils.getCanonicalHostName.

A complete fix now could be for the admin console to retrieve the cert for alias s1as from the keystore, get the X500 principal for the cert, get the DN from the X500 principal, and then parse the DN to get the CN .

A better fix - probably for a later release - is for create-domain to persist the user-specified keytooloptions value in domain.xml so the console can use them (if present) to compute the correct host name.

Comment by Anissa Lam [ 07/Jan/11 ]

Hi Tim,
Thanks for your time again.
The exception occurs before it ever called the verify() method in HostnameVerifier.

Once these 2 lines is executed:
HTTPSProperties httpsProperties = new HTTPSProperties(new BasicHostnameVerifier( serverName) );
client.getProperties().put(HTTPSProperties.PROPERTY_HTTPS_PROPERTIES, httpsProperties);

the next request will get an exception.

Caused by: java.lang.IllegalStateException: SSLContextImpl is not initialized
at com.sun.net.ssl.internal.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:145)
at javax.net.ssl.SSLContext.getSocketFactory(SSLContext.java:260)
at com.sun.jersey.client.urlconnection.HTTPSProperties.setConnection(HTTPSProperties.java:140)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:166)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 32 more

Comment by Anissa Lam [ 07/Jan/11 ]

One more hurdle that needs to jump through is that, I don't even have the 'client' to set the HTTPSPproperties.

The work flow in the AdminConsoleAuthModule is:

1. when first launching GUI, ensure authentication, which means show the login page.
2. Before loading the login page, we have code to call REST-endpoint/anonymous-login-enabled
3. if authenticated (with or without password)
4. Login succeed, create a client.

so, before step 2, we should have the hostname verifier setup, since we need to call REST to see if anonymous login is enabled. But the client hasn't created yet.

The code that i have been trying is using a debugger to force the REST-endpoint/anonymous-login-enabled to match the CN so i can go pass it.

I am attaching the 2 files AdminConsoleAuthModule and RestUtil that has my experimental code.

For AdminConsoleAuthModule, at line #196,
rd.forward(request, response);
is the line that will try to load the login page.

line# 218
ClientResponse resp = webResource.accept(RESPONSE_TYPE).post(ClientResponse.class);

is when the above exception occurs.

The hostname Verifier code can be found at the end of RestUtil.java

Comment by Tim Quinn [ 07/Jan/11 ]

Earlier in the separate e-mail thread I suggested that the console might need to initialize the HTTPSProperties object differently. I've pasted part of that message next.

When the caller does not specify an SSLContext on the HTTPSProperties constructor, Jersey (according to its JavaDoc) tries to get a normal default one. Judging from the last part of the stack trace, the SSLContext it gets is not set up.

A possible quick solution worth trying is to instantiate HTTPProperties this way:

@Inject
private SSLUtils sslUtils; // from the security/core module, I think

@Inject
private Habitat habitat;

SecureAdmin secureAdmin = habitat.getComponent(SecureAdmin.class);
String dasAlias = SecureAdmin.Util.getDasAlias(secureAdmin);

new HTTPProperties(new BasicHostnameVerifier(serverName), sslUtils.getAdminSSLContext(dasAlias, null));

Comment by kumarjayanti [ 09/Jan/11 ]

I followed the steps on my MAC, if i test with Jan-7th workspace I am seeing the following in GUI after accepting the Certificates in the Browser :

URL : https://localhost:4848/common/index.jsf

Internal Server Error - Read

The server encountered an internal error or misconfiguration and was unable to complete your request.
Reference #3.4fe2fc7d.1294643868.ddbf42

And there is nothing at all in the logs. the last message in admin GUI is :

[#|2011-01-10T12:44:44.799+0530|WARNING|glassfish3.1|org.glassfish.admingui|_ThreadID=25;_ThreadName=Thread-1;|Cannot create update center Image for /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3; Update Center functionality will not be available in Admin Console|#]

I do not have a windows system and i am wondering in what way i can help this issue.

Comment by kumarjayanti [ 10/Jan/11 ]

With latest builds on my MAC everything works fine. The exception being reported in the issue relates to hostname verification and it cannot be Windows specific right ?

Caused by: java.security.cert.CertificateException: No name matching localhost f
ound
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)

So has this issue been fixed ?. Can i close the issue.

Please add a description of how this has been fixed.

Comment by kumarjayanti [ 10/Jan/11 ]

ignore my last two comments, i realized that the issue only comes when a Domain is created with CN=FQDN and not with default domain in the zip installed glassfish.

Comment by kumarjayanti [ 10/Jan/11 ]

I added the following code to admingui/common/..../RestUtil.java

Index: src/main/java/org/glassfish/admingui/common/util/RestUtil.java
===================================================================
— src/main/java/org/glassfish/admingui/common/util/RestUtil.java (revision 44351)
+++ src/main/java/org/glassfish/admingui/common/util/RestUtil.java (working copy)
@@ -45,6 +45,8 @@

package org.glassfish.admingui.common.util;

+import javax.net.ssl.HostnameVerifier;
+import javax.net.ssl.SSLSession;
import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
import com.sun.jersey.api.client.WebResource;
@@ -93,6 +95,21 @@
private static final String REST_TOKEN_COOKIE = "gfresttoken";

+ static {
+
+ javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(
+ new HostnameVerifier() {
+ public boolean verify(String host, SSLSession sslSession) {
+ if (host.equals("localhost"))

{ + return true; + }

+ return host.equals(sslSession.getPeerHost());
+ }
+
+ });
+ }
+
+
public static String getPropValue(String endpoint, String propName, HandlerContext handlerCtx){

}

This fixes the problem, the AdminGUI loads up fine . Like i said before with the latest builds you should not see the SSLContext not initialized problem.

Now on my MAC when i tried to print the Certificate of domain1 it shows :

CN=dhcp-cblr03-213-110.india.sun.com

But within the verify method i put a System.out of the following form :
System.out.println("host=" + host + " sslSession.getPeerHost()=" + sslSession.getPeerHost());

I see the following in server.log :
[#|2011-01-10T15:28:21.244+0530|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=90;_ThreadName=Thread-1;|host=localhost sslSession.getPeerHost()=localhost|#]

IOW commenting the following code :

+ if (host.equals("localhost"))

{ + return true; + }

from the hostnameverifier still makes it work.

I would request you guys to just carefully experiment what the code in the verify method should be and make the final fix.

reassigning the Bug to Anissa, so she can reassign it to appropriate person.

Comment by Anissa Lam [ 10/Jan/11 ]

Thanks Kumar for helping out.
I have tried your suggestion and tested it for different scenario and it is working fine.
I will do more testing and request for approval for fixing this.

Comment by Tim Quinn [ 10/Jan/11 ]

Are we sure we want to set the default hostname verifier? This will affect the hostname verifier for all URL connections?

There should be a way for this part of the GUI code to set the hostname verifier and the SSL socket factory if needed for just its connection, not as the default, right?

Comment by kumarjayanti [ 10/Jan/11 ]

Tim is right.

What i did was just experimental to prove that setting a hostnameverifier is the final solution to this problem.

If Rest API's provides a way to set it for the connection we should continue to use that. I believe Anissa was already doing that, i don't want it to be changed to this form.

The first thing the hostnameverifier should do is check if host == CN of the server certificate (this can be retrieved from SSLSession object passed). If that check returns false then we can try to relax it by the check i put above host.equals(sslSession.getPeerHost()). You could get the base code from JDK's default HostnameVerifier and then add these additional checks to relax the constraints.

Comment by Anissa Lam [ 10/Jan/11 ]

Thats true, the hostname verifier is able to resolve the problem.
Based on everyone's input including Tim, Abhijit, Mitesh and Kumar, I have the following code and tested that it seems to be working fine in all different scenario. I have given the patch to Shaline to test out as well. Once she confirms that it is working as expected, I will send the approval request and formal review.

Here is my latest code, and seems to be working.

public static void initialize(Client client){
if (client == null)

{ client = JERSEY_CLIENT; }

try

{ Habitat habitat = SecurityServicesUtil.getInstance().getHabitat(); SecureAdmin secureAdmin = habitat.getComponent(SecureAdmin.class); HTTPSProperties httpsProperties = new HTTPSProperties(new BasicHostnameVerifier(), habitat.getComponent(SSLUtils.class).getAdminSSLContext(SecureAdmin.Util.DASAlias(secureAdmin), null )); client.getProperties().put(HTTPSProperties.PROPERTY_HTTPS_PROPERTIES, httpsProperties); }

catch(Exception ex)

{ ex.printStackTrace(); }

}

private static class BasicHostnameVerifier implements HostnameVerifier {
public BasicHostnameVerifier() {
}
public boolean verify(String s, SSLSession sslSession)

{ return true; }
public boolean verify(String s) { return true; }

}

Comment by Anissa Lam [ 10/Jan/11 ]

One more thing, I see that the REST code test if secure admin is enabled before adding the hostname verifier. I am going to do the same. But even if i set that up, it won't be called if secure admin is not enabled, is that correct ?

Comment by kumarjayanti [ 10/Jan/11 ]

hostnameverifier won't be invoked unless https is used for accessing admin.

The code for verify methods does not seem appropriate. Please consider using the following :

final HostnameVerifier defaultVerifier =
javax.net.ssl.HttpsURLConnection.getDefaultHostnameVerifier();

public boolean verify(String host, SSLSession sslSession) {

boolean result = defaultVerifier.verify(host, sslSession);
if (!result)

{ result = host.equals(sslSession.getPeerHost()); }

if (!result) {
if (host.equals("localhost"))

{ result = true; }

}
return result;

}

Also the javax.net.ssl.HostnameVerifier has a single method :

boolean verify(String hostname, SSLSession session)

So why do you need the second method verify(String s) there ?.

Comment by Anissa Lam [ 10/Jan/11 ]

I tried changing to what you suggested above. GUI works fine too.

I just notice one issue. Although GUI works fine, if i go to
http://localhost:4848/management/domain in the browser,
I will get this exception. This happens both before and after changing to what u suggest for verify().

[#|2011-01-10T19:58:22.412-0800|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=27;_ThreadName=admin-thread-pool-4848(27);|processorTask.exceptionSSLcert
javax.net.ssl.SSLHandshakeException: Insecure renegotiation is not allowed
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:635)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:689)
at com.sun.grizzly.util.SSLUtils.doPeerCertificateChain(SSLUtils.java:559)
at com.sun.grizzly.filter.SSLReadFilter.doPeerCertificateChain(SSLReadFilter.java:340)
at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:153)
at com.sun.grizzly.tcp.Request.action(Request.java:430)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getAttribute(GrizzlyRequest.java:835)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getUserPrincipal(GrizzlyRequest.java:1834)
at org.glassfish.admin.rest.adapter.RestAdapter.authenticateViaAdminRealm(RestAdapter.java:304)
at org.glassfish.admin.rest.adapter.RestAdapter.authenticate(RestAdapter.java:227)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:163)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)

#]
Comment by Anissa Lam [ 10/Jan/11 ]

I also see this exception once or twice when i try to deploy an application.
During all my testing, i saw this only 2 times out of over 30 times.

[#|2011-01-10T20:32:40.794-0800|SEVERE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=25;_ThreadName=admin-thread-pool-4848(43);|GRIZZLY0040: Request header is too large.
java.nio.BufferOverflowException
at com.sun.grizzly.tcp.http11.InternalInputBuffer.fill(InternalInputBuffer.java:765)
at com.sun.grizzly.tcp.http11.InternalInputBuffer.parseHeader(InternalInputBuffer.java:615)
at com.sun.grizzly.tcp.http11.InternalInputBuffer.parseHeaders(InternalInputBuffer.java:555)
at com.sun.grizzly.http.ProcessorTask.parseRequest(ProcessorTask.java:871)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:692)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)

#]

and the browser will show:
Secure Connection Failed

An error occurred during a connection to localhost:4848.

SSL received a record that exceeded the maximum permissible length.

(Error code: ssl_error_rx_record_too_long)

  • The page you are trying to view can not be shown because the authenticity of the received data could not be verified.
  • Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.
Comment by kumarjayanti [ 10/Jan/11 ]

---------

I just notice one issue. Although GUI works fine, if i go to
http://localhost:4848/management/domain in the browser,
I will get this exception. This happens both before and after changing to what u suggest for verify().

[#|2011-01-10T19:58:22.412-0800|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=27;_ThreadName=admin-thread-pool-4848(27);|processorTask.exceptionSSLcert
javax.net.ssl.SSLHandshakeException: Insecure renegotiation is not allowed
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:635)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:689)
at com.sun.grizzly.util.SSLUtils.doPeerCertificateChain(SSLUtils.java:559)
--------

So which version of JDK are you using for the testing. Make sure you use JDK 1.6.0_22 or later.

http://www.java.net/blog/kumarjayanti/archive/2010/11/18/ssl-renegotiation-issue-fixed-jdk16022

Comment by kumarjayanti [ 10/Jan/11 ]

Link to grizzly issue which suggests using _22.

http://java.net/jira/browse/GRIZZLY-915

Comment by kumarjayanti [ 10/Jan/11 ]

-------------
also see this exception once or twice when i try to deploy an application.
During all my testing, i saw this only 2 times out of over 30 times.

[#|2011-01-10T20:32:40.794-0800|SEVERE|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=25;_ThreadName=admin-thread-pool-4848(43);|GRIZZLY0040: Request header is too large.
java.nio.BufferOverflowException
at com.sun.grizzly.tcp.http11.InternalInputBuffer.fill(InternalInputBuffer.java:765)
at com.sun.grizzly.tcp.http11.InternalInputBuffer.parseHeader(InternalInputBuffer.java:615)
at com.sun.grizzly.tcp.http11.InternalInputBuffer.parseHeaders(InternalInputBuffer.java:555)
--------------

First upgrade to JDK _22 and after that if you still see this error, then file a bug on grizzly with steps to reproduce it.

Comment by Anissa Lam [ 10/Jan/11 ]

I am using jdk 22. I don't think you can run secure admin if you have version less than that.
I am using Mac, and here is my jdk.

116) java -version
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)

Comment by Anissa Lam [ 11/Jan/11 ]

How bad is its impact? (Severity)
Very Severe.

How often does it happen? (Frequency)
Everytime when a new domain is created or using the domain that the installer create, GUI is not accessible if secure-admin is turned on.

How much effort is required to fix it? (Cost)
Several days for me, mainly because i am not familiar in the security area.

What is the risk of fixing it? (Risk)
The risk should should be minor, it won't hurt the non-secure admin case. And if secure-admin is turned on, it was mostly broken anyway.

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?
We have to fix this. Release Note is not good enough.

Here is the svn diff. The patch created with this code change has been tested extensively by me, and given to Shalini to tested out. Basic sanity check from Shalini for different scenario worked without issue.
This code is reviewed by Tim. I will request review from Mitesh as well.

~/Awork/V3/v3 25) svn diff admingui
Index: admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java
===================================================================
— admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (revision 44400)
+++ admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java (working copy)
@@ -68,6 +68,7 @@
import org.jvnet.hk2.component.Habitat;
import com.sun.enterprise.config.serverbeans.Domain;
import com.sun.enterprise.security.SecurityServicesUtil;
+import org.glassfish.admingui.common.util.RestUtil;

/**

  • <p> This class is responsible for providing the Authentication support
    @@ -192,7 +193,8 @@
    // Not passed in, show the login page...
    RequestDispatcher rd = request.getRequestDispatcher(loginPage);
    try { - rd.forward(request, response); + RestUtil.initialize(null); + rd.forward(request, response); }

    catch (Exception ex) {
    AuthException ae = new AuthException();
    ae.initCause(ex);
    @@ -208,7 +210,10 @@
    // new PasswordValidationCallback(clientSubject, username, pwd);

// Make REST Request

  • WebResource webResource = Client.create().resource(restURL);
    +
    + Client client2 = Client.create();
    + RestUtil.initialize(client2);
    + WebResource webResource = client2.resource(restURL);
    webResource.addFilter(new HTTPBasicAuthFilter(username, password));
    ClientResponse resp = webResource.accept(RESPONSE_TYPE).post(ClientResponse.class);
    RestResponse restResp = RestResponse.getRestResponse(resp);
    Index: admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java
    ===================================================================
      • admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java (revision 44400)
        +++ admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java (working copy)
        @@ -72,6 +72,14 @@

import org.glassfish.admingui.common.security.AdminConsoleAuthModule;

+import javax.net.ssl.HostnameVerifier;
+import javax.net.ssl.SSLSession;
+import com.sun.enterprise.security.SecurityServicesUtil;
+import com.sun.enterprise.config.serverbeans.SecureAdmin;
+import com.sun.enterprise.security.ssl.SSLUtils;
+import com.sun.jersey.client.urlconnection.HTTPSProperties;
+import org.jvnet.hk2.component.Habitat;
+
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.Node;
@@ -710,4 +718,35 @@
//******************************************************************************************************************
// Jersey client methods
//******************************************************************************************************************
+ public static void initialize(Client client){
+ if (client == null)

{ + client = JERSEY_CLIENT; + }

+ try

{ + Habitat habitat = SecurityServicesUtil.getInstance().getHabitat(); + SecureAdmin secureAdmin = habitat.getComponent(SecureAdmin.class); + HTTPSProperties httpsProperties = new HTTPSProperties(new BasicHostnameVerifier(), + habitat.getComponent(SSLUtils.class).getAdminSSLContext(SecureAdmin.Util.DASAlias(secureAdmin), null )); + client.getProperties().put(HTTPSProperties.PROPERTY_HTTPS_PROPERTIES, httpsProperties); + }

catch(Exception ex){
+ GuiUtil.getLogger().warning("RestUtil.initialize() failed");
+ if (GuiUtil.getLogger().isLoggable(Level.FINE))

{ + ex.printStackTrace(); + }

+ }
+ }
+
+ private static class BasicHostnameVerifier implements HostnameVerifier {
+ final HostnameVerifier defaultVerifier = javax.net.ssl.HttpsURLConnection.getDefaultHostnameVerifier();
+ public BasicHostnameVerifier()

{ + }

+
+ public boolean verify(String host, SSLSession sslSession) {
+ if (host.equals("localhost"))

{ + return true; + }

+ boolean result = defaultVerifier.verify(host, sslSession);
+ return (result) ? true : host.equals(sslSession.getPeerHost());
+ }
+ }
}

Comment by Anissa Lam [ 11/Jan/11 ]

The change in the hostname verifier was based on the last comment from Kumar.
Tim and Mitesh has reviewed the code, and a patch thats created based on this change has been confirmed by QA that this fixed the issue. So i checked in the fix.

Project: glassfish
Repository: svn
Revision: 44412
Author: anilam
Date: 2011-01-12 05:34:09 UTC
Link:

Log Message:
------------
Fix GLASSFISH-15421. add hostname verifier so that GUI is accessible when secure-admin is on, regardless what the CN of the cert is set to.
A patch based on this code change was created for QA to verify the fix and QA confirmed this fixed the issue.

Approved: self-approve
Reviewer: Tim Quinn, Mitesh

Revisions:
----------
44412

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/security/AdminConsoleAuthModule.java
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java

Comment by shaline [ 25/Jan/11 ]

Verified in promoted b38.





[GLASSFISH-15534] Http Status 404 shown when JVM settings/Path Settings Cancel button is clicked. Created: 11/Jan/11  Updated: 21/Feb/11  Resolved: 11/Jan/11

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

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

env: Windows 2008 Server
Browser: IE and firefox 3.6


Tags: 3_1-approved, 3_1-verified

 Description   

GF Build used : nightly dated b37-01-11-2011
In the Console click on the Cancel button in the server-config/JVM Settings/Path Settings Page.

The below 404 Status is thrown.

HTTP Status 404 -

type Status report

message

descriptionThe requested resource () is not available.
Oracle GlassFish Server 3.1



 Comments   
Comment by Anissa Lam [ 11/Jan/11 ]

There should not be any Cancel button on this page. There isn't a 'list' page for this page to go back to, so according to the GUI convention, the cancel button shouldn't be there.

How bad is its impact? (Severity)
Very unprofessional to show a 404 on screen.

How often does it happen? (Frequency)
Everytime when user goes to the JVM Path page and then click the Cancel button.

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

What is the risk of fixing it? (Risk)
no risk. Just remove the button.

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

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
No. it won't help.

~/Awork/V3/v3/admingui 153) svn diff common

Index: common/src/main/resources/javaConfig/jvmPath_2.inc
===================================================================
— common/src/main/resources/javaConfig/jvmPath_2.inc (revision 44400)
+++ common/src/main/resources/javaConfig/jvmPath_2.inc (working copy)
@@ -73,12 +73,6 @@
gf.redirect(page="#

{selfPage}

&alertType=$

{alertType}

&alertSummary=$

{alertSummary}

&alertDetail=$

{alertDetail}

");
/>
</sun:button>
-

  • <sun:button id="cancelButton" immediate="# {true}

    " primary="#

    {false}

    " rendered="#

    {pageSession.showCancelButton}

    " text="$resource

    {i18n.button.Cancel}

    " >

  • <!command
  • gf.redirect(page="# {parentPage}

    ?configName=#

    {configName}

    ");

  • />
  • </sun:button>
    </sun:panelGroup>
    </facet>
Comment by Anissa Lam [ 11/Jan/11 ]

Project: glassfish
Repository: svn
Revision: 44417
Author: anilam
Date: 2011-01-12 07:28:29 UTC
Link:

Log Message:
------------
Fix GLASSFISH-15534. Remove the Cancel button from JVM Path page. It shouldn' be there at all.

Approved: self-approve
Reviewer: Suma, Srini

Revisions:
----------
44417

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/resources/javaConfig/jvmPath_2.inc

Comment by shaline [ 24/Jan/11 ]

verified on promoted b38.





[GLASSFISH-15551] appclient does not work on windows with cygwin Created: 12/Jan/11  Updated: 20/Feb/11  Due: 18/Jan/11  Resolved: 14/Jan/11

Status: Closed
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1_b36
Fix Version/s: 3.1_b38

Type: Bug Priority: Blocker
Reporter: gopaljorapur Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved, 3_1-blocking, 3_1-verified

 Description   

appclient fails on windows with cygwin

Here is the log

> /cygdrive/c/ha/glassfish3/glassfish/ config
> $ C:/ha/glassfish3/glassfish/bin/appclient -client C:/ha/ file_repository//appclient/cartClient.jar -xml C:/ha/ file_repository//appclient/sun-acc.xml++ dirname C:/ha/glassfish3/ glassfish/bin/appclient
> + _AS_INSTALL=C:/ha/glassfish3/glassfish/bin/..
> + export _AS_INSTALL
> + case "`uname`" in
> ++ uname
> ++ cygpath --windows C:/ha/glassfish3/glassfish/bin/..
> + _AS_INSTALL='C:\ha\glassfish3\glassfish\'
> + . 'C:\ha\glassfish3\glassfish\/config/asenv.conf'
> ++ AS_IMQ_LIB=../../mq/lib
> ++ AS_IMQ_BIN=../../mq/bin
> ++ AS_CONFIG=../config
> ++ AS_INSTALL=..
> ++ AS_DEF_DOMAINS_PATH=../domains
> ++ AS_DEF_NODES_PATH=../nodes
> ++ AS_DERBY_INSTALL=../../javadb
> ++ AS_JAVA=C:/ha/jdk1.6.0_23
> + chooseJava
> + '[' C:/ha/jdk1.6.0_23 '!=' '' ']'
> + javaSearchType=AS_JAVA
> + javaSearchTarget=C:/ha/jdk1.6.0_23
> + JAVA=C:/ha/jdk1.6.0_23/bin/java
> + '[' '!' -x C:/ha/jdk1.6.0_23/bin/java ']'
> ++ C:/ha/jdk1.6.0_23/bin/java -classpath 'C:\ha\glassfish3\glassfish \/lib/gf-client.jar' org.glassfish.appclient.client.CLIBootstrap - client C:/ha/file_repository//appclient/cartClient.jar -xml C:/ha/ file_repository//appclient/sun-acc.xml
> + eval '"C:\ha\jdk1.6.0_23\jre\bin\java.exe"' '- Dcom.sun.aas.installRoot="C:\ha\glassfish3\glassfish"' '- Djava.security.policy="C:\ha\glassfish3\glassfish\lib\appclient \client.policy"' - Djava .system .class .loader=org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader 'Djava.security.auth.login.config="C:\ha\glassfish3\glassfish\lib \appclient\appclientlogin.conf"' '-Djava.ext.dirs="C:\ha \glassfish3\glassfish\lib\ext";"C:\ha\jdk1.6.0_23\jre\lib\ext"' ' Djava.endorsed.dirs="C:\ha\glassfish3\glassfish\lib\endorsed";"C:\ha \glassfish3\glassfish\modules\endorsed";"C:\ha\jdk1.6.0_23\jre\lib \endorsed"' 'javaagent:"C:\ha\glassfish3\glassfish\lib\gf client.jar"=mode=acscript,arg=configxml,arg="C:\ha \glassfish3\glassfish\domains\domain1\config\sun acc.xml",client=jar="C:/ha/file_repository//appclient/ cartClient.jar",arg=xml,arg="C:/ha/file_repository//appclient/sun acc.xml"' -jar '"C:/ha/file_repository//appclient/cartClient.jar"' $'\r'
> ++ 'C:\ha\jdk1.6.0_23\jre\bin\java.exe' '-Dcom.sun.aas.installRoot=C: \ha\glassfish3\glassfish' '-Djava.security.policy=C:\ha \glassfish3\glassfish\lib\appclient\client.policy' - Djava .system .class .loader=org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader '-Djava.security.auth.login.config=C:\ha\glassfish3\glassfish\lib \appclient\appclientlogin.conf' '-Djava.ext.dirs=C:\ha \glassfish3\glassfish\lib\ext'
> C:/ha/glassfish3/glassfish/bin/appclient: line 107: C:\ha \jdk1.6.0_23\jre\bin\java.exe: command not found
> ++ 'C:\ha\jdk1.6.0_23\jre\lib\ext' '-Djava.endorsed.dirs=C:\ha \glassfish3\glassfish\lib\endorsed'
> C:/ha/glassfish3/glassfish/bin/appclient: line 107: C:\ha \jdk1.6.0_23\jre\lib\ext: command not found
> ++ 'C:\ha\glassfish3\glassfish\modules\endorsed'
> C:/ha/glassfish3/glassfish/bin/appclient: line 107: C:\ha \glassfish3\glassfish\modules\endorsed: command not found
> ++ 'C:\ha\jdk1.6.0_23\jre\lib\endorsed' 'javaagent:C:\ha \glassfish3\glassfish\lib\gf-client.jar=mode=acscript,arg= configxml,arg=C:\ha\glassfish3\glassfish\domains\domain1\config\sun- acc.xml,client=jar=C:/ha/file_repository//appclient/ cartClient.jar,arg=xml,arg=C:/ha/file_repository//appclient/sun acc.xml' -jar C:/ha/file_repository//appclient/cartClient.jar $'\r'
> C:/ha/glassfish3/glassfish/bin/appclient: line 107: C:\ha \jdk1.6.0_23\jre\lib\endorsed: command not found
>
>



 Comments   
Comment by Tim Quinn [ 13/Jan/11 ]

As I said to Gopal in e-mail, I suspect the problem is this.

The appclient script runs a java command executing CLIBootstrap, which in turn computes a second java command which actually launches the ACC. CLIBootstrap uss conventional techniques to determine what OS is current so it can use the correct path separator character. When running on Windows, even under cygwin, Java reports the separator character as '\' and the path separator char as ';' and so CLIBootstrap creates a java command using those characters. Further, CLIBootstrap prepares the second java command to run java.exe.

I think cygwin appends another .exe to the file path to find the actual executable on the Windows system, and of course java.exe.exe is not present in the Java installation. That causes the error message that java.exe cannot be found. The subsequent errors are because cygwin seems to be interpreting the ; Windows path separator which CLIBootstrap used as command separators as *nix shells do.

It may be a simple matter of CLIBootstrap detecting not only if the OS is Windows but also whether cygwin is the current shell. The appclient script can pass an additional property to CLIBootstrap to indicate this if needed. Elena has allowed me to use an SQE Windows test system with cygwin installed to work on this further.

Comment by Tim Quinn [ 13/Jan/11 ]

updating fix version

Comment by Tim Quinn [ 13/Jan/11 ]

Review discussion:

How bad is its impact? (Severity)
This is a regression and is causing sqe tests using Windows and cygwin to fail. Users will have the same problems in that environment.

How often does it happen? (Frequency)
Always with Windows and cygwin.

How much effort is required to fix it? (Cost)
I already have a fix I am testing.

What is the risk of fixing it? (Risk)
Low. The change consists of very simple changes to the appclient script (adding env var assignments and adding env var substitutions on a command to pass information into the CLIBootstrap class) plus a handful of parallel changes in CLIBoostrap.java to use these properties if/when they are defined.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
There is 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 [ 14/Jan/11 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 44520
Author: tjquinn
Date: 2011-01-15 00:41:33 UTC
Link:

Log Message:
------------
Fix for 15551

The app client CLIBootstrap class, which prepares the actual java command to launch the ACC, needed to use Unix-style path separators if the user is on Windows but running under cygwin.

These changes pass some additional information from the appclient and appclient.bat scripts to CLIBootstrap by env vars and a property.

Approved: Nazrul
Code Reviewed: Byron

Tests: QL, deployment and ejb devtests; manual tests on Windows with and without cygwin

Revisions:
----------
44520

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
trunk/v3/appclient/client/appclient-scripts/src/main/resources/glassfish/bin/appclient.bat





[GLASSFISH-15667] "Launch" link non-existent for Virtual Server deployed app Created: 24/Jan/11  Updated: 24/Jan/11  Resolved: 24/Jan/11

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

Type: Bug Priority: Minor
Reporter: Ed Burns 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



 Description   

Deploy an app to virtual servers using a command such as this:

./asadmin --port 60048 deploy --virtualservers mojarra-virtual-server1,mojarra-virtual-server2 --target mojarra-cluster appname

Visit the page for the app in the adminGUI

The "Launch" link will be blank.



 Comments   
Comment by Anissa Lam [ 24/Jan/11 ]

This has been fixed in 3.1
Shaline (our QA) has confirmed this.

>> I created 2 virtual servers in CLI, and deployed an application to these 2 VS using CLI, and in the AdminConsole, I checked that the "Launch" link showed up, for this deployed app.
>> I also created 2 Vs from the Console, and deployed an application to these 2 VS in the Console, the "Launch " link shows up for the deployed app.
>> So this issue does not exist in V3.1.
>>
>> Thank you
>> Shaline.

Marking this as resolved in 3.1





[GLASSFISH-4182] gfv3: OEM Pluggability: GUI Look and Feel Created: 15/Feb/08  Updated: 22/Jan/11  Resolved: 22/Jan/11

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

Type: New Feature Priority: Blocker
Reporter: msreddy 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: Sun


Issuezilla Id: 4,182
Status Whiteboard:

v3-prd-item


 Description   

This is a GUI Look and Feel dependent issue for the umbrella issue# 4176.

Provide Infrastruture/API so that the OEM modules can customize the look and feel.



 Comments   
Comment by msreddy [ 15/Feb/08 ]

this is a P1 requirement ...

Comment by msreddy [ 26/Feb/08 ]

v3-prd-item

Comment by Anissa Lam [ 28/Feb/08 ]

This is AdminConsole-006 specified in
http://wiki.glassfish.java.net/Wiki.jsp?page=V3AdminConsoleImprovements

Provide a way to customize the UI itself, e.g. themes, skins etc.

Comment by Anissa Lam [ 22/Jan/11 ]

GUI allows module with different theme to plugin since v3. Currently we have community theme and Oracle branded one.
Mark as resolved.





[GLASSFISH-15601] update-node-ssh - improve error message Created: 18/Jan/11  Updated: 19/Jan/11  Resolved: 19/Jan/11

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

Type: Bug Priority: Major
Reporter: Harshad Vilekar Assignee: Joe Di Pol
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved

 Description   

Negative Scenario: Try to update non existing node. Make sure it fails with meaningful message.

$ asadmin update-node-ssh xxx
remote failure: There is no node named "null" in this domain.
Command update-node-ssh failed.

Expected Message: remote failure: There is no node named "xxx" in this domain.



 Comments   
Comment by Joe Di Pol [ 19/Jan/11 ]

There is a typo in the code where it is passing the node object instead of the node name when constructing the string. The fix is:

if (node == null) {

  • String m = Strings.get("noSuchNode", node);
    + String m = Strings.get("noSuchNode", name);
Comment by Joe Di Pol [ 19/Jan/11 ]

How bad is its impact? (Severity)
This is an in-your-face issue that may be seen by a large number of customers. The consequences aren't severe, but it makes the product look sloppy and unprofessional.

How often does it happen? (Frequency)
Any time you run update-node-ssh with an invalid node name. So it can be seen in typical use of the product.

How much effort is required to fix it? (Cost)
Very low effort. I must change 4 characters.

What is the risk of fixing it? (Risk)
Very low risk. The change only impacts this one error message and it is a simple change.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
The workaround is to ignore mistake in the error message.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Probably not. It has no severe impact other than lack of fit and finish.

Comment by Chris Kasso [ 19/Jan/11 ]

Approved for 3.1

Comment by Joe Di Pol [ 19/Jan/11 ]

Fixed in 3.1

Project: glassfish
Repository: svn
Revision: 44621
Author: jfdipol
Date: 2011-01-19 21:14:49 UTC
Link:

Log Message:
------------
15601 update-node-ssh - improve error message
Fix a typo in an error message parameter in update-node-ssh command.

Code Review: Carla
Approved: Kasso





[GLASSFISH-15278] WELD-000612 Unable to deserialize field. Declaring bean id org.jboss.weld.bean Created: 20/Dec/10  Updated: 18/Jan/11  Due: 18/Jan/11  Resolved: 18/Jan/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_b38

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

linux, latest glassfish 3.1, clustered setup


Attachments: Zip Archive number-guess.zip     Text File server.log     File weld-numberguess.war    
Issue Links:
Duplicate
is duplicated by GLASSFISH-15395 session not replicated due to non-ser... Resolved
Status Whiteboard:

weld-int-required

Tags: cdi, cluster, glassfish, glassfish-3-1, weld-int-required

 Description   

This issue is with number guess sample.This sample is also failing in multi machine cluster setup.It was working with single machine setup.

In a single instance setup, we are deploying the app to an instance say instance101 , then bringing the instance 101 down and then again restarting the instance then continuing with the app.

But when we have the webserver and loadbalancing setup, this is failing.

Exception:
==========

[#|2010-12-20T20:53:32.329+0530|SEVERE|glassfish3.1|org.apache.catalina.connector.CoyoteAdapter|_ThreadID=16;_ThreadName=Thread-1;|PWC3989: An exception or error occurred in the container during the request processing
org.jboss.weld.exceptions.IllegalStateException: WELD-000612 Unable to deserialize field. Declaring bean id org.jboss.weld.bean-/space/sony/builds/glassfish3/glassfish/nodes/agent3/instance102/applications/weld-numberguess/-ManagedBean-class org.jboss.weld.examples.numberguess.Game, declaring class public@SessionScoped @Named class org.jboss.weld.examples.numberguess.Game, field name randomNumber
at org.jboss.weld.injection.FieldInjectionPoint$SerializationProxy.readResolve(FieldInjectionPoint.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at java.util.ArrayList.readObject(ArrayList.java:593)
at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.apache.catalina.session.StandardSession.readRemainingObject(StandardSession.java:1951)
at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1859)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at org.apache.catalina.session.StandardSession.deserialize(StandardSession.java:1144)
at org.apache.catalina.session.StoreBase.readSession(StoreBase.java:288)
at org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:542)
at org.glassfish.web.ha.session.management.ReplicationStore.getSession(ReplicationStore.java:494)
at org.glassfish.web.ha.session.management.ReplicationStore.loadFromBackingStore(ReplicationStore.java:413)
at org.glassfish.web.ha.session.management.ReplicationStore.load(ReplicationStore.java:396)
at org.glassfish.web.ha.session.management.ReplicationStore.load(ReplicationStore.java:391)
at org.apache.catalina.session.PersistentManagerBase.doSwapIn(PersistentManagerBase.java:1055)
at org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentManagerBase.java:1016)
at org.apache.catalina.session.PersistentManagerBase.swapIn(PersistentManagerBase.java:982)
at org.apache.catalina.session.PersistentManagerBase.findSession(PersistentManagerBase.java:738)
at org.apache.catalina.session.ManagerBase.findSession(ManagerBase.java:876)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2834)
at org.apache.catalina.connector.Request.getSession(Request.java:2561)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:920)
at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:623)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:323)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]


 Comments   
Comment by Sreekanth [ 20/Dec/10 ]

number-guess.zip contains the logs generated from the clustered environment.The issue can be observed in the instance 4 server log.

Comment by Sreekanth [ 20/Dec/10 ]

attaching War file being used.

Comment by Sivakumar Thyagarajan [ 29/Dec/10 ]

Weld seems to have a non-serializable Class (org.jboss.weld.injection.SimpleInjectionPoint) in the injected Bean and hence serialization of the session fails.

[#|2010-12-29T15:32:49.105+0530|INFO|glassfish3.1|org.apache.catalina.session.ManagerBase|_ThreadID=16;_ThreadName=Thread-1;|PWC2785: Cannot serialize session attribute org.jboss.weld.context.ConversationContext.conversations for session 19458e718e99f064f17ad1e3ea7a
java.io.NotSerializableException: org.jboss.weld.injection.SimpleInjectionPoint
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at java.util.HashMap.writeObject(HashMap.java:1001)
at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:2067)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at org.apache.catalina.session.StoreBase.writeSession(StoreBase.java:269)
at org.glassfish.web.ha.session.management.HAStoreBase.getByteArray(HAStoreBase.java:229)
at org.glassfish.web.ha.session.management.ReplicationStore.doValveSave(ReplicationStore.java:147)
at org.glassfish.web.ha.session.management.ReplicationWebEventPersistentManager.doValveSave(ReplicationWebEventPersistentManager.java:157)
at org.glassfish.web.ha.session.management.HASessionStoreValve.doPostInvoke(HASessionStoreValve.java:175)
at org.glassfish.web.ha.session.management.HASessionStoreValve.postInvoke(HASessionStoreValve.java:136)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:670)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:323)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2010-12-29T15:32:49.143+0530|INFO|glassfish3.1|org.apache.catalina.session.ManagerBase|_ThreadID=16;_ThreadName=Thread-1;|PWC2785: Cannot serialize session attribute

Comment by Sivakumar Thyagarajan [ 29/Dec/10 ]

Attaching the server.log showing the session serialization failure

Comment by Sivakumar Thyagarajan [ 29/Dec/10 ]

Filed https://issues.jboss.org/browse/WELD-812 to track this.

Comment by Sivakumar Thyagarajan [ 04/Jan/11 ]

This issue has been partially resolved as part of WELD-812, but there are still some problems around de-serialization of the Conversation and session. I am working with the Weld team and will close this issue after we resolve that.

Comment by Sivakumar Thyagarajan [ 18/Jan/11 ]

Resolved through commits 44592 to 44594 by an integration of Weld 1.1.0.Final.





[GLASSFISH-15142] wl-run-as-principal-name unit test unstable Created: 13/Dec/10  Updated: 18/Jan/11  Resolved: 18/Jan/11

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

Type: Bug Priority: Major
Reporter: Amy Roh Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Failure.png     PNG File Successful.png    
Tags: 3_1-approved

 Description   

wl-run-as-principal-name unit test is failing in hudson about 50% of the times making the build unstable. The failure is also reproducible non-hudon environment. It isn't clear that the test needs to be updated to be more robust or this bug only happens occasionally.

[java] Unexpected return code: 500
[java] Generating report at /files/hudson/workspace/webtier-dev-tests-v3/appserv-tests/test_results.xml
[java]
[java]
[java] -----------------------------------------
[java] - wl-run-as-principal-name: FAIL -
[java] -----------------------------------------
[java] - Total PASS : 0 -
[java] - Total FAIL : 1 -
[java] - Total DID NOT RUN : 0 -
[java] -----------------------------------------

[#|2010-12-13T12:52:17.244-0800|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=15;_ThreadName=Thread-1;|WEB0671: Loading application [web-wl-run-as-principal-name-web] at [/web-wl-run-as-principal-name]|#]

[#|2010-12-13T12:52:17.259-0800|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=15;_ThreadName=Thread-1;|web-wl-run-as-principal-name-web was successfully deployed in 1,338 milliseconds.|#]

[#|2010-12-13T12:52:17.892-0800|INFO|glassfish3.1|javax.enterprise.system.core.security|_ThreadID=15;_ThreadName=Thread-1;|JACC Policy Provider: Failed Permission Check, context(web-wl-run-as-principal-name-web/web-wl-run-as-principal-name-web_internal)- permission((javax.security.jacc.EJBMethodPermission StatelessBean hello,Local,))|#]

[#|2010-12-13T12:52:17.893-0800|WARNING|glassfish3.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=15;_ThreadName=Thread-1;|A system exception occurred during an invocation on EJB StatelessBean method public java.lang.String test.StatelessBean.hello()
javax.ejb.AccessLocalException: Client not authorized for this invocation.
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1885)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy127.hello(Unknown Source)
at test._EJB31_GeneratedStatelessBeanIntf__Bean_.hello(Unknown Source)
at test.TestServlet.doGet(TestServlet.java:60)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]

[#|2010-12-13T12:52:17.945-0800|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=15;_ThreadName=Thread-1;|Standar
dWrapperValve[test.TestServlet]: PWC1406: Servlet.service() for servlet test.TestServlet threw exceptionjavax.ejb.EJBAccessException
at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2314)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2088)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy127.hello(Unknown Source)
at test._EJB31_GeneratedStatelessBeanIntf__Bean_.hello(Unknown Source)
at test.TestServlet.doGet(TestServlet.java:60)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation.
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1885)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
... 31 more

#]


 Comments   
Comment by Shing Wai Chan [ 14/Dec/10 ]

The test fails occasionally.
When it passes, the generated policy is as follows:
grant

{ permission javax.security.jacc.WebResourcePermission "/:/mytest"; permission javax.security.jacc.WebUserDataPermission "/mytest"; permission javax.security.jacc.WebUserDataPermission "/:/mytest"; }

;

grant principal org.glassfish.security.common.PrincipalImpl "aprincipal"

{ permission javax.security.jacc.WebRoleRefPermission "", "arole"; permission javax.security.jacc.WebRoleRefPermission "jsp", "arole"; permission javax.security.jacc.WebRoleRefPermission "test.TestServlet", "arole"; permission javax.security.jacc.WebRoleRefPermission "default", "arole"; }

;

grant principal org.glassfish.security.common.PrincipalImpl "javaee"

{ permission javax.security.jacc.WebResourcePermission "/mytest"; permission javax.security.jacc.WebRoleRefPermission "", "javaee"; permission javax.security.jacc.WebRoleRefPermission "default", "javaee"; permission javax.security.jacc.WebRoleRefPermission "test.TestServlet", "javaee"; permission javax.security.jacc.WebRoleRefPermission "jsp", "javaee"; };

When it fails, the generated policy is as follows:
grant { permission javax.security.jacc.WebResourcePermission "/:/mytest"; permission javax.security.jacc.WebUserDataPermission "/mytest"; permission javax.security.jacc.WebUserDataPermission "/:/mytest"; };

grant principal org.glassfish.security.common.PrincipalImpl "javaee" { permission javax.security.jacc.WebResourcePermission "/mytest"; permission javax.security.jacc.WebRoleRefPermission "", "javaee"; permission javax.security.jacc.WebRoleRefPermission "default", "javaee"; permission javax.security.jacc.WebRoleRefPermission "test.TestServlet", "javaee"; permission javax.security.jacc.WebRoleRefPermission "jsp", "javaee"; }

;

Notice that in the case of failure, the block for "aprincipal" is missing.

Comment by Nithya Ramakrishnan [ 14/Jan/11 ]

It appears that during the cases in which the test fails, EjbBundleValidator.computeRunAsPrincipalDefault is never invoked. This seems to be because the WebComponentDescriptor.runAs is null instead of being assigned the value from the weblogic.xml. Since the runAs is not set to the valid value, it causes the policies to be incorrectly generated in the security code.

Attaching the screenshots of the successful case - where the WebComponentDescriptor.runAs has a valid value and the failure case, where runAs always has a null value.

Assigned back to Shing Wai for appropriate re-assignment.

Comment by Nithya Ramakrishnan [ 14/Jan/11 ]

Screenshots of successful and failure cases - Debugger results

Comment by Shing Wai Chan [ 18/Jan/11 ]

I have fixed a typo in the test case.
I still see random behavior by just running that particular test.

The WebComponentDescriptor.runAs object is null. This means that @RunAs is not processed in this case.

Comment by Shing Wai Chan [ 18/Jan/11 ]

How bad is its impact? (Severity)
High as related to security

How often does it happen? (Frequency)
Random.

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?
no

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

Comment by Shing Wai Chan [ 18/Jan/11 ]

Sending src/main/java/com/sun/enterprise/deployment/annotation/handlers/RunAsHandler.java
Transmitting file data .
Committed revision 44583.





[GLASSFISH-15576] admin gui upgrade failure when grizzly schema upgrade doesn't happen first Created: 14/Jan/11  Updated: 18/Jan/11  Resolved: 18/Jan/11

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

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

Solaris Sparc 10


Attachments: File patch0.diff     Text File server.log    
Tags: 3_1-approved, 3_1-upgrade

 Description   

Tested latest promoted b37

Performed an upgrade of V2.1.1. Cluster Profile to V3.1

When clicking on admin GUI to list JDBC resources I see the following error snippet from server.log (attached all the server.log error portion as attachment)

[#|2011-01-14T11:00:26.874-0500|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=30;_ThreadName=Thread-1;

Internal Server error: /management/domain/resources/jdbc-resource/jdbc%2F__CallFlowPool
java.io.CharConversionException: Encoded slashes are not allowed by default. To enable encodedslashes, set the property com.sun.griz
zly.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true.
at com.sun.grizzly.util.buf.UDecoder.convert(UDecoder.java:151)
at com.sun.grizzly.util.buf.UDecoder.convert(UDecoder.java:257)
at com.sun.grizzly.util.buf.UDecoder.convert(UDecoder.java:235)
at com.sun.grizzly.util.http.HttpRequestURIDecoder.decode(HttpRequestURIDecoder.java:98)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:185)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
#]

[#|2011-01-14T11:00:26.877-0500|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=116;_Thread
Name=Thread-1;|Unsupported Response Format: 'text/html'!|#]

[#|2011-01-14T11:00:26.877-0500|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=23;_ThreadName=Thread-1;|RestResponse.getRespons
e() gives FAILURE. endpoint = 'http://localhost:4848/management/domain/resources/jdbc-resource/jdbc%2F__CallFlowPool'; attrs = '{}'|
#]



 Comments   
Comment by adf59 [ 14/Jan/11 ]

The following also shows on the GUI admin console:

Error An error has occurred
REST Request 'http://localhost:4848/management/domain/resources/jdbc-resource/jdbc%2F__CallFlowPool' failed with response code '500'.

Comment by Bobby Bissett [ 14/Jan/11 ]

This is at least the 3rd time I've seen this issue come up. For instance, GLASSFISH-15032 was the last one. I also see the error in this build http://dlc.sun.com.edgesuite.net/glassfish/3.1/promoted/glassfish-3.1-b37.zip but I don't see it in this morning's workspace. Someone should make sure this was fixed on purpose and not by accident (or at least add a unit test for it that gets run on promoted builds).

Possibly related: I see this error message during an upgrade from the promoted build but I don't see it in this morning's workspace:

asadmin: SEVERE: Could not upgrade security service for admin console: org.jvnet.hk2.config.TransactionFailure: Can't operate without <http-service>

The order of modules performing upgrades is different in the promoted builds than in the workspace for whatever reason. (That's what caused issue GLASSFISH-15195.) So I think that the admin console security update service needs to figure out what module should run before it and simply inject an instance of that class to force the ordering.

Comment by Bobby Bissett [ 14/Jan/11 ]

Am moving to the admin gui team to see if it's related to the upgrade error message I included. I'll see if I can find the source to reproduce this. We really don't want some bug escaping because it only happens in promoted builds and not workspaces.

Tom's nice description of a similar problem:
http://java.net/jira/browse/GLASSFISH-15195?focusedCommentId=148935&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_148935

Comment by Bobby Bissett [ 14/Jan/11 ]

Art, can you verify that you're also seeing the TransactionFailure during the upgrade? That might be a useful datum while I'm building the b37 sources.

Comment by Bobby Bissett [ 14/Jan/11 ]

I can reproduce this with this workspace:
https://svn.java.net/svn/glassfish~svn/tags/3.1-b37

Comment by Bobby Bissett [ 14/Jan/11 ]

Whoo-hoo. This is fixed with a simple forcing of the ordering of modules performing upgrade tasks. I've attached a patch that fixes the issue, namely:

1. Giving a service name to admin/config-api/src/main/java/org/glassfish/config/support/GrizzlyConfigSchemaMigrator
2. Injecting that service into core/kernel/src/main/java/com/sun/enterprise/v3/admin/AdminRESTConfigUpgrade like this:

@Inject(name="grizzlyconfigupgrade", optional=true)
ConfigurationUpgrade precondition = null;

That forces GrizzlyConfigSchemaMigrator#postConstruct to be run before AdminRESTConfigUpgrade#postConstruct is run. Thus the upgrade succeeds and the JDBC resource can be fetched properly by the admin console.

Will run more tests now with this patch while sending info to change committee.

Comment by Bobby Bissett [ 14/Jan/11 ]

How bad is its impact? (Severity)
It's a regression. Without this, users can't access JDBC resources in admin GUI after an upgrade.

How often does it happen? (Frequency)
This issue is similar to GLASSFISH-15195. I suspect the issue will never happen in the workspace trunk, but will always happen in promoted builds. It all depends on the way hk2 orders components returned by Habitat#getInhabitants(). Given that, for a particular build the problem will either always happen or never happen.

How much effort is required to fix it? (Cost)
Done and done. Based on the work for GLASSFISH-15195, the fix was simply finding the right precondition and injecting that service into the admin rest upgrade service. Diff is attached.

What is the risk of fixing it? (Risk)
The fix was suggested by Jerome. I'm unaware of any risks unless people make more changes that could introduce a circular dependency.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Um, if we could figure out why promoted builds are different from workspace builds, maybe there's a workaround. The changes I've suggested are a lot simpler though, and only affect the code that runs during upgrade (no changes during runtime).

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Big time. This would be a major problem for users, at least the users who use the admin console.

Comment by Chris Kasso [ 14/Jan/11 ]

Approved for 3.1

Comment by Bobby Bissett [ 18/Jan/11 ]

Changing summary to the root issue.

Comment by Bobby Bissett [ 18/Jan/11 ]

Fixed in revision 44560 with the patch attached to this issue.





[GLASSFISH-15586] Parameter associate-with-thread fails when activated for more than one pool Created: 15/Jan/11  Updated: 17/Jan/11  Resolved: 16/Jan/11

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

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved

 Description   

Raising this issue for 3.1 release.

Original issue : GLASSFISH-15577
http://java.net/jira/browse/GLASSFISH-15577

Refer the original issue for more details.



 Comments   
Comment by Jagadish [ 15/Jan/11 ]

Yes, this is an issue. It seems that the thread-local is declared as static for the pool which is incorrect. It should be declared per instance of pool.

Comment by Jagadish [ 15/Jan/11 ]

1. How bad is its impact? (Severity)

  • Identify why the fix needs to occur now:
    o Likely to generate a customer support call
    o An in-your-face issue that will touch the majority of users
    2. How often does it happen? (Frequency)
  • When more than one jdbc-connection-pool has "associate-with-thread" flag enabled.
    3. How much effort is required to fix it? (Cost)
  • Simple, instead of using static thread-local variable, use per instance thread-local.
    4. What is the risk of fixing it? (Risk)
  • None, fix is localized to associate-with-thread.
  • All tests passed : QL (Web, Classic), connector-dev, jdbc-dev, connector-standalone-cts (Web, Classic), resources-admin-cli, connector-sqe
  • Will also be adding a new test-case for this particular scenario in jdbc dev-tests.
    5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
  • No workaround other then disabling the flag altogether.
    6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
  • NA
Comment by Jagadish [ 16/Jan/11 ]

svn log -v -r 44526

Modified Paths:
---------------
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/AssocWithThreadResourcePool.java

Comment by marsangr [ 17/Jan/11 ]

I can reproduce the problem in Glassfish Open Source Edition 2.1.1
Could somebody apply the same patch to it?





[GLASSFISH-15474] [Stress][Blocking] RichAccess failing on OEL because of OOM or "message count limit has been reached" Created: 06/Jan/11  Updated: 14/Jan/11  Due: 18/Jan/11  Resolved: 14/Jan/11

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: None
Fix Version/s: 3.1_b38

Type: Bug Priority: Blocker
Reporter: easarina Assignee: amyk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-15494 The imq.cluster.brokerlist is not get... Closed
depends on MQ-75 limited consumer flowcontrol becomes ... Closed
Tags: 3_1-blocking

 Description   

Build 37 nightly, Jan. 05. OEL5 machines.

The build was installed on three machines. DAS plus one instance, on asqe-x2250-st5, the other two instances on asqe-x2250-st6 & asqe-x2250-st7. In the cluster, the Stress Application, RichAccess, was deployed. Against each instance in the cluster, a test client was running and sending http requests at a rate that is equivalent to 100 simultaneous users per instance. MQ was set in Embedded mode. Heap size was 768Mb.

After about one hour of running, either an Out of Memory (OOM) error occurred or the following messages were posted in the MQ log:

[05/Jan/2011:07:31:19 PST] WARNING [B2011]: Storing of JMS message from IMQConn[AUTHENTICATED,guest@127.0.0.1:22300,null] failed:
com.sun.messaging.jmq.jmsserver.util.BrokerException: [B4120]: Can not store message 9048323-10.133.184.161(ca:3d:25:9a:7a:46
)-22300-1294241479417 on destination richAppTopic [Topic]. The destination message count limit (maxNumMsgs) of 100000 has been reached.

It looks like the OOM condition or "message count limit has been reached" issues were caused by the same problem. It was observed that the MQ messages were slowly consumed.

For this reason, we believe, the stress Test crashed on this setup.



 Comments   
Comment by Satish Kumar [ 07/Jan/11 ]

The strange part about this bug is that the stress tests seem to be reporting this warning only on this particular set of machines. Sony and Varun have confirmed that the tests have run for several days on other machines including in OEL and the memory usage did not seem abnormal in any of these setups.

As has been pointed out in a previous comment, the message consumption rate appears to be too slow causing the head size to grow steadily and eventually resulting in MQ reporting this warning. Stopping the client from sending new messages appears to result in the messages being eventually consumed but at a very slow pace.

One issue that was noticed while debugging this setup is that the imq.cluster.brokerlist is not being populated correctly. Although this does appear to be directly related to this issue, this could cause an imbalance in the client connections to the broker.

Comment by sb110099 [ 07/Jan/11 ]

This bug was filed after a joint debugging session with Mahesh, Amy and Sony.

Here are follow-up notes from Amy after that :

"Thanks to Mahesh for spending time yesterday examing the GlassFish servers and Thanks to everyone for yesterday's joined debug session.

  • The message production rate is greater than the message consumption rate as observed yesterday on Elena's setup
    suggestions:
  • reduce load to reduce message production rate
  • increase MDB pool size to speed up message consumption
  • lower max. message limit on the destination richAppTopic
  • increase Jave heap size (for EMBEDDED mode needs much heap than LOCAL/REMOTE)
  • use FLOW_CONTROL on destination limitBehavior (throttle the message producer)
  • The test as its setup now, need to run with balanced message production and consumption rates
  • to monitor message in/out rates: imqcmd metrics dst -t t -n richAppTopic -m rts
  • The OOM as shown in the broker log was "java.lang.OutOfMemoryError: GC overhead limit exceeded"
    which explains why JVM threw OOM even though broker was rejecting new messages under destination full
    suggestions:
  • configure the test to run in a balanced message production/consumtion rate to avoid destination full
  • increase heap size
    or
  • configure the test to run in FLOW_CONTROL destination limitBehavior (default REJECT_NEW)
  • Satish has found an issue in broker addressList in GlassFish/JMS last night which could cause uneven-distribution of client connections to brokers

Additional info for Sony when he experiments more with the test: Embedded broker in standalone instance uses ra-direct mode whereas embedded broker in 1-instance cluster uses tcp mode as does in n-instance cluster.

The following 2 bugs noticed in the broker logs (no functional impact):
7010855 - NPEs logged when GlassFish EMBEDDED broker shutdown due to unrecoverable OOM
MQ-74 - broker logs NPE when debug dump broker in GlassFish EMBEDDED JMS mode
"

Comment by Nazrul [ 07/Jan/11 ]

This is blocking stress testing

Comment by Nazrul [ 13/Jan/11 ]

Amy is workin on MQ-75 issue. So assigning to her.

Comment by amyk [ 14/Jan/11 ]

MQ 4.5 build25, which contains fixes for MQ-75(7011163), 7011169 and MQ-74, has been integrated and should be in GlassFish 3.1 Jan 13's nightly build and next promoted build





[GLASSFISH-15556] Privileged code block missing in osgi-resource-locator module Created: 13/Jan/11  Updated: 13/Jan/11  Resolved: 13/Jan/11

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1_b36
Fix Version/s: 3.1_b38

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

Issue Links:
Dependency
blocks GLASSFISH-15536 JaxwsFromWsdl test in QL fails with s... Resolved
Tags: 3_1-approved

 Description   

See GLASSFISH-15536 where the following is reported while running quicklook/wsit/JaxwsFromWsdl test with security manager:

[#|2011-01-12T22:12:27.979+0530|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=101;_ThreadName=Thread-1;|java.lang.ClassNotFoundException: No permission.
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:900)
at org.glassfish.hk2.osgiresourcelocator.ServiceLoaderImpl.lookupProviderClasses1(ServiceLoaderImpl.java:128)
at org.glassfish.hk2.osgiresourcelocator.ServiceLoader.lookupProviderClasses(ServiceLoader.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.lookupUsingOSGiServiceLoader(ContextFinder.java:423)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:379)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
at com.sun.xml.ws.fault.SOAPFaultBuilder.<clinit>(SOAPFaultBuilder.java:565)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:269)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:314)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:608)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:259)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.invokeAsync(ServletAdapter.java:207)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:159)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:194)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:80)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:322)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:355)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:212)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1527)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.security.AccessControlException: access denied (org.osgi.framework.AdminPermission (id=232) class,resolve)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:895)
... 60 more

#]

[#|2011-01-12T22:12:27.983+0530|INFO|glassfish3.1|javax.enterprise.system.core.security|_ThreadID=20;_ThreadName=Thread-1;|JACC Policy Provider: Failed Permission Check, context(JaxwsFromWsdl/JaxwsFromWsdl)- permission((org.osgi.framework.AdminPermission (id=101) resolve,resource))|#]

How bad is its impact? Severe as it impacts product security

How often does it happen? (Frequency) Always

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

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?

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



 Comments   
Comment by Chris Kasso [ 13/Jan/11 ]

Approved for 3.1

Comment by Sanjeeb Sahoo [ 13/Jan/11 ]

Sending pom.xml
Transmitting file data .
Committed revision 44470.





[GLASSFISH-15443] NullPointerException in com.sun.enterprise.resource.pool.PoolManagerImpl.getJavaName Created: 05/Jan/11  Updated: 12/Jan/11  Resolved: 12/Jan/11

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_b38

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

Linux


Attachments: Zip Archive NPEBugTest.zip    
Tags: 3_1-approved

 Description   

calling getConnection on a DataSource results in an intermittent NullPointerException in getJavaName as follows:

com.sun.enterprise.resource.pool.PoolManagerImpl.getJavaName(PoolManagerImpl.java:539)
com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceReference(PoolManagerImpl.java:530)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:175)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:160)
com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:110)
com.kickstone.pricegoblin.data.goblin.GoblinData.getProduct(GoblinData.java:173)
...

where the calling class is defined as:
@ManagedBean
public class GoblinData {
...
public void getProduct(URI uri){
...
Retailer retailer=null;
try

{ retailer=(Retailer)em.createNamedQuery("Retailer.findByExternalUri").setParameter("externalUri", externalUri).getSingleResult(); }

catch (NoResultException ex)

{ return; // TODO - retailer not matched }

...
try {
Connection c=null;
try

{ c=ds.getConnection(); ... }

finally

{ if (c!=null) c.close(); }

} catch (SQLException ex){
}
}

@PersistenceContext(unitName="PriceGoblinPU")
private EntityManager em;

@Resource(mappedName="jdbc/frontendDB")
private DataSource ds;
}

and the datasource is defined as:

<jdbc-connection-pool validation-table-name="connection_validation" pool-resize-quantity="2" datasource-classname="org.postgresql.ds.PGSimpleDataSource" max-pool-size="32" wrap-jdbc-objects="false" res-type="javax.sql.ConnectionPoolDataSource" steady-pool-size="2" description="PostgreSql" name="FrontendDB">
<property name="PortNumber" value="xxx"></property>
<property name="Password" value="xxx"></property>
<property name="ServerName" value="xxx"></property>
<property name="DatabaseName" value="xxx"></property>
<property name="User" value="xxx"></property>
</jdbc-connection-pool>
<jdbc-resource pool-name="FrontendDB" jndi-name="jdbc/frontendDB"></jdbc-resource>

Looking at the code, the only time logicalName is null (which is passed to getJavaName) is when an entityManager is used, if a DataSource is injected, it is always set.

If you require any more info, then let me know



 Comments   
Comment by jsl123 [ 05/Jan/11 ]

Apologies, this has somehow been assigned to the load-balancer component. I thought I left the component selection blank.

Comment by Jagadish [ 06/Jan/11 ]

Please provide a test-case (eg: .war) which can be used to reproduce the issue, if it is easy for you.

Comment by jsl123 [ 06/Jan/11 ]

I'll try and get a test case, but it happens only intermittently and I've only seen it on our forward facing boxes with reasonably high load. The only thing I've noticed is that it occurred more frequently when I'd inadvertently used the debug connection pool settings which had a very small pool, so I figured it was related to the connection pool having no spare connections.

Comment by Jagadish [ 07/Jan/11 ]

Looking at the stack trace, this issue can happen only in the following setup.
Application component has multiple "resource-ref"s defined for same resource.

eg: jdbc-resource by jndi-name "my-resource" is referred by (atleast) two resource-refs

<resource-ref>
<res-ref-name>logical-name-1</res-ref-name>
<jndi-name>my-resource</jndi-name>
</resource-ref>

<resource-ref>
<res-ref-name>logical-name-2</res-ref-name>
<jndi-name>my-resource</jndi-name>
</resource-ref>

Workaround would be to
a) Use same logical-name (only one resource-ref per resource) in the application
or
b) Create another resource pointing to same pool and map it for the second resource-ref.
[This is simple as jdbc-resource is referring the jdbc-connection-pool and jdbc-connection-pool is shared by multiple jdbc-resources.]

Please confirm whether your setup is similar to the environment stated above and the workaround solves your issue.

Changing the priority as we are gone past HCF and workaround is available.

Comment by jsl123 [ 07/Jan/11 ]

On my forward facing server, I have 2 resource-refs defined as follows in the domain.xml config file:
<resource-ref ref="jdbc/frontendDB"></resource-ref>
<resource-ref ref="jdbc/backendDB"></resource-ref>

neither includes a jndi name explicitly, but use the resource with the same name. both resources point to different pools. On my debug machines, the resource-refs are the same, the only difference is that the 2 resources point at the same connection pool.

Other than the global config, I don't define any references in my application config files.

I've also been working on a test case and I may be able to replicate it using jmeter and loading up the requests - I need to verify the results are repeatable.

Additionally, debugging the app, the multiple references are caused by the fact I inject the datasource into multiple managed beans. The list it iterates through contains a list along the lines of:
com.kickstone.pricegoblin.resources.Home/ds
com.kickstone.pricegoblin.data.GoblinData/ds
etc
if that helps

Comment by jsl123 [ 08/Jan/11 ]

Some more information - I can get partial repeatability with my main app using jmeter, so going to strip out the relevant parts and post a sample war file. In addition, the problem is with logicalName, it just happens to be triggered if there are multiple references defined. Looking through the source and partially debugging it, this could be a problem with Weld not setting the logical name and thus leaving it as null.

Comment by Jagadish [ 10/Jan/11 ]

I could make the following use-case resulting in NPE.

eg:

Class MyBean {
@Resource(mappedName="jdbc/__default")
DataSource ds1;

@Resource(mappedName="jdbc/__default")
DataSource ds2;

private void doDBOperation()

{ InitialContext ic = new InitialContext(); DataSource ds = (DataSource) ic.lookup("jdbc/__default") Connection con = ds.getConnection(); // FAIL with same NPE as reported in the initial bug-report }

}

Doing an initialContext.lookup("jdbc/_default") in the class where two DataSources (of same resource-name ie., "jdbc/_default) is injected or specified via <resource-ref> in application descriptors will result in the above NPE.

Fix would be to make sure that "logicalName" is not null while comparing the resource-ref names.
logicalName will be null in case of jndi-name based (physical) lookups. (eg: initialContext.lookup('jdbc/__default')

jsl123 : Please let me know whether your code-base has initialContext based lookup of resource in the class where the same resource is also injected multiple times. (similar to above use-case)

Comment by jsl123 [ 10/Jan/11 ]

Netbeans Web Archive Project that exhibits the described behaviour

Comment by jsl123 [ 10/Jan/11 ]

Hi, I've attached a test case that demonstrates the problem on my machine running pretty much a vanilla Glassfish v3.1.36 install. I've stripped out everything from my main project that doesn't seem to be needed.

I don't follow the schema of your testcase as my classes are managed beans and the datasource is injected by the container, finally the multiple references are in separate classes and have different logicalNames - see below for details of testcase

I only use the datasource.getConnection so that I can generate Arrays which are vendor specific. The tables, database settings will need changing to meet your needs, otherwise it should be fairly straightforward. The project includes a jmeter test which causes the problem about 1 in 500 hits although you need to heavily load it to get a failure so ramping up of the settings may be needed - equally I could only see the error when not in the debugger...

The project contains the following features which seem to contribute to the problem:

  • Uses Jersey Rest implementation with 2 resource entry points - home and product. The latter is to be called and generates the error.
  • the Datasource is injected into 2 different classes (home & goblindata) which result in the 2 distinct references in getResourceReference. The logical name is a concatenation of the class and member name, the jndi name is as expected.
  • I use an entity Manager (based on a persistenceUnit using the same database resource) as well as this seems to have null for the logicalName, in addition its jdni name has _nontx appended - which I found confusing.
  • all the classes used are managed by the container (CDI beans)

The test case doesn't really do anything, although as it stands the first db call should succeed in order to get the connection and trigger the error.

Let me know if you have any problems (or I've done something stupid in my implementation)

Comment by Jagadish [ 11/Jan/11 ]

Thanks for sharing the test-case, I tried the test-case using jmeter and could not reproduce it in varied load, multiple times.

  • I tried it using Derby (create a jdbc-resource named jdbc/frontendDB
    asadmin create-jdbc-resource --connectionpoolid DerbyPool jdbc/frontendDB
  • DDL :
    create table retailer_retailer ( id integer primary key, date_created date, last_modified date, external_uri varchar(100), name varchar(50), description varchar(200))

> I use an entity Manager (based on a persistenceUnit using the same database
> resource) as well as this seems to have null for the logicalName, in addition its jdni
> name has _nontx appended - which I found confusing.

Yes, JPA uses the resource (in persistence.xml) which will account for physical lookup with __nontx suffix which is for internal purposes to get a non-transactional connection. This is expected.

> the Datasource is injected into 2 different classes (home & goblindata) which result in
> the 2 distinct references in getResourceReference
Yes, since these are defined in the .war, all of the resource-references (@Resource) will be shared within the jndi environment of the .war.

Comment by jsl123 [ 11/Jan/11 ]

Hi, do you have a matching entry in the retailer table to the url passed into the rest method? Otherwise as the code stands it will drop out and therefore doesn't create the connection explictly from the Datasource which is what results in the error. For reference, the error happens on line 45 in GoblinData.java.

You may also need to create another table:

CREATE TABLE django.summary_map (
id integer primary key,
offer_id integer,
template integer,
position integer,
value character varying
)

which is used, although I only use a query against it so merged the query into the retailer entity object so you may not have spotted it...

Comment by Jagadish [ 11/Jan/11 ]

How bad is its impact? (Severity)

  • Likely to generate a customer support call
    How often does it happen? (Frequency)
  • Whenever multiple "resource-ref" or @Resource injections for same resource happens and the component also does physical lookup of the resource (rather than injection).

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

  • Fix is to introduce not null check for logicalName so that this issue is avoided.

What is the risk of fixing it? (Risk)

  • Minimal as it happens in the above use-case and the fix is localized to this specific use-case.

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

  • For this particular use-case, no workaround exists. Only option for the user is to change the code to avoid doing physical lookup which might be difficult.

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

  • N.A

All tests passed : QL (Web, Classic), connector-dev, jdbc-dev, connector-standalone-cts (Web, Classic), resources-admin-cli and the use-case I have posted.
Since I could not reproduce the exact setup by the bug-submitter, requested bug-submitter to test the fix and got confirmation that the fix resolves the issue for him.

Will also add a dev-test for this scenario.

Comment by Jagadish [ 12/Jan/11 ]

svn log -v -r 44427

Modified Paths:
---------------
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/PoolManagerImpl.java

Also added a test-case : refer README
svn log -v -r 44429
Modified Paths:
---------------
trunk/v2/appserv-tests/devtests/jdbc/connsharing/nonxa/ejb/SimpleSession.java
trunk/v2/appserv-tests/devtests/jdbc/connsharing/nonxa/descriptor/ejb-jar.xml
trunk/v2/appserv-tests/devtests/jdbc/connsharing/nonxa/ejb/SimpleSessionBean.java
trunk/v2/appserv-tests/devtests/jdbc/connsharing/nonxa/client/Client.java
trunk/v2/appserv-tests/devtests/jdbc/connsharing/nonxa/README





Generated at Wed Mar 04 20:46:29 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.