[GLASSFISH-15769] Regression: Weaving attempted in Glassfish embedded even though supposedly disabled Created: 31/Jan/11  Updated: 13/Feb/11  Resolved: 04/Feb/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1_b39
Fix Version/s: 3.1_ms08

Type: Bug Priority: Critical
Reporter: ljnelson Assignee: Mitesh Meswani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved, 3_1-fishcat

 Description   

Weaving is apparently disabled-or at least that's the intent-in Glassfish embedded.

However, when I use the embeddable Glassfish APIs, documented at http://embedded-glassfish.java.net/nonav/apidocs/, it appears that weaving is attempted.

I have an EJB project set up with a persistence unit in it. So, some classes are EJB interfaces, others are EJB implementations, and others are entity classes. There is a META-INF/persistence.xml file in there. javax.ejb.embeddable.EJBContainer deploys this "archive" fine.

I've recently switched over to using the Glassfish embeddable APIs instead, since they are more robust (they support remote EJBs among other things). I've made no other changes.

At test time, I get the exception message detailed by this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=323403

That is, EclipseLink 2.2.0 is attempting to invoke a weaving-supplied method, even though weaving is disabled.

I suspect that something about the way weaving is "disabled" is not in fact fully disabling it.

In point of fact, I would like weaving to be ON. But I understand that this is an issue with an embedded API.

I can work around this issue if I explicitly set weaving to be off in my persistence.xml file:

<property name="eclipselink.weaving" value="false"/>

...but I'd rather not do that.



 Comments   
Comment by Mitesh Meswani [ 03/Feb/11 ]

Weaving was always disabled in embedded mode to guard against use cases where entity classes are touched (and hence loaded) by the app before transformers get installed. JPADeployer relied on serverEnvironment.isEmbedded() to determine if it is being run in embedded mode. Embedded implementation has recently changed to not answer true for serverEnvironment.isEmbedded() causing the regression. After discussions, it seems instead of always disabling weaving, a more flexible approach would be to enabled it by default and give user an option to explicitly disable it for embedded. Following diffs implements the change

Index: src/main/java/org/glassfish/persistence/jpa/JPADeployer.java
===================================================================
— src/main/java/org/glassfish/persistence/jpa/JPADeployer.java (revision 44872)
+++ src/main/java/org/glassfish/persistence/jpa/JPADeployer.java (working copy)
@@ -42,6 +42,7 @@

import com.sun.appserv.connectors.internal.api.ConnectorRuntime;
import com.sun.enterprise.deployment.*;
+import com.sun.enterprise.module.bootstrap.StartupContext;
import com.sun.logging.LogDomains;
import org.glassfish.api.deployment.DeployCommandParameters;
import org.glassfish.api.event.EventListener;
@@ -84,6 +85,9 @@
private ServerEnvironmentImpl serverEnvironment;

@Inject
+ private volatile StartupContext sc = null;
+
+ @Inject
private Events events;

@Inject
@@ -196,7 +200,13 @@
@Override void visitPUD(PersistenceUnitDescriptor pud, DeploymentContext cont
ext) {
if(referencedPus.contains(pud)) {
boolean isDas = isDas();

  • ProviderContainerContractInfo providerContainerContractInfo = serverEnvironment.isEmbedded() ?
    +
    + // While running in embedded mode, it is not possible to guarantee that entity classes are not loaded by the app classloader before transformers are installed
    + // If that happens, weaving will not take place and EclipseLink will throw up. Provide users an option to disable weaving by passing the flag.
    + // Note that we enable weaving if not explicitly disabled by user
    + boolean weavingEnabled = Boolean.valueOf(sc.getArguments().getProperty("org.glassfish.persistence.embedded.weaving.enabled", "true"));
    +
    + ProviderContainerContractInfo providerContainerContractInfo = weavingEnabled ?
    new EmbeddedProviderContainerContractInfo(context, connectorRuntime, isDas) :
    new ServerProviderContainerContractInfo(context, connectorRuntime, isDas);
    PersistenceUnitLoader puLoader = new PersistenceUnitLoader(pud, providerContainerContractInfo);
Comment by Mitesh Meswani [ 03/Feb/11 ]

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

  • Is a regression of functionality from prior release.
  • With this issue present, if an app needs to disable weaving for embedded, the app's persistence.xml needs to be changed. This is quite inconvenient for unit test scenarios (The main use case for embedded)

How often does it happen? (Frequency)

  • For any app that needs to disable weaving

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

  • The fix is available and is attached in previous comment

What is the risk of fixing it? (Risk)

  • Minimal to no risk. The fix is localized to embedded use case. I have verified in debugger that nothing is changed for non embedded case.

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

  • Work around is to modify persistence.xml to explicitly disable weaving. This makes using embedded for unit testing inconvenient

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

  • Yes

How long has the bug existed in the product?

  • Not more than a month

Do regression tests exist for this issue?

  • No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • The standard QE test suit against derby. I have already run them with these changes.

When will a tested fix be ready for integration?

  • It is available now.
Comment by Mitesh Meswani [ 03/Feb/11 ]

Checked in the code branch rev 44890, trunk rev 44889

Comment by Mitesh Meswani [ 03/Feb/11 ]

Assigning to docs to document the property "org.glassfish.persistence.embedded.weaving.enabled" in Embedded guide

Comment by Sanjeeb Sahoo [ 03/Feb/11 ]

I am not convinced by the change. There seem to be an assumption made about embedded which is not true. Why can't weaving be disabled outside embedded mode? Similarly, what happens when weaving has not disabled in embedded mode using this system property, but it has been explicitly disabled using persistence.xml? Are we loosing out any functionality by not using EmbeddedProviderContractInfo? Or, is it just a matter of name here?

Comment by Mitesh Meswani [ 03/Feb/11 ]

What do you mean by weaving disabled outside embedded mode?

> what happens when weaving has not disabled in embedded mode using this system property, but it has been explicitly disabled using persistence.xml?
It will be disabled.

>Are we loosing out any functionality by not using EmbeddedProviderContractInfo? Or, is it just a matter of name here?
No. It is just matter of name. EmbeddedProviderContractInfo currently just provides isWeavingDisabled(). Once the trunk opens up, I am inclined towards removing the class with some refactoring.

Comment by marina vatkina [ 03/Feb/11 ]

I'm confused... ServerEnvironmentImpl.isEmbedded() returns true in static-shell run of the EJB Timer Service...

Comment by marina vatkina [ 04/Feb/11 ]

All JPA tests in embedded ejb devtests failed - see http://hudson-sca.us.oracle.com/job/ejb-devtests-v3/281/

Comment by Mitesh Meswani [ 04/Feb/11 ]

Checked in 44918 in trunk and 44919 in branch.
The check in disables weaving for embedded EJB container case as was before. The status now is:
-Weaving is enabled by default when GlassFish Emedded API is used. It can be disabled by specifying property "org.glassfish.persistence.embedded.weaving.enabled" as "false"
-Weaving is disabled for embedded EJB container use case.

This behavior is not yet stable and can be changed in future versions of GlassFish.

Comment by ljnelson [ 04/Feb/11 ]

Thanks for your hard work.

Comment by Sanjeeb Sahoo [ 04/Feb/11 ]

Replying to Mitesh's response:

> What do you mean by weaving disabled outside embedded mode?
What this means is for whatever reason, someone may like to disable weaving in regular glassfish - e.g., someone wants to measure benefits of weaving, but they don't want to change their persistence.xmls to set the property. In such a case, the new system property can be very handy.

>> what happens when weaving has not disabled in embedded mode using this system property, but it has been explicitly disabled using persistence.xml?
> It will be disabled.
That's the desired behavior.

>> Are we loosing out any functionality by not using EmbeddedProviderContractInfo? Or, is it just a matter of name here?
> No. It is just matter of name. EmbeddedProviderContractInfo currently just provides isWeavingDisabled(). Once the trunk opens up, > I am inclined towards removing the class with some refactoring.

I look forward to this improvement to improve clarity in the code.

Thanks.

Comment by ljnelson [ 10/Feb/11 ]

Please also see http://java.net/jira/browse/GLASSFISH-13688





[GLASSFISH-15768] IIOP Loadbalancing not happening with old styled applications Created: 31/Jan/11  Updated: 20/Feb/11  Resolved: 03/Feb/11

Status: Closed
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1_ms08
Fix Version/s: 3.1_ms08

Type: Bug Priority: Critical
Reporter: gopaljorapur Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved, 3_1-verified

 Description   

IIOP Loadbalancing not happening with old styled application

1. Start Cluster with 5 instances
2. Create 12 InitialContext in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see 12 of them in only one instance (incorrect behavior, load should be loadbalanced across cluster)

The test code is as follows

/// When we run appclient, we provide test id as RMIIIOPFOTC4, this creates 12 ic and 12 sfsb remote ref

if(testid.equals("RMIIIOPFOTC4"))
{
for(int i=0;i<12;i++)

{ client.createContextForACC(); client.createSFSBRemoteRef(); }

System.out.println("Test Passed");
}

//// Here is how ic is created

public void createContextForACC()
{
try

{ Context initial = new InitialContext(); myEnv = (Context)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

///// Here is how sfsb remote ref is
public void createSFSBRemoteRef()
{
try

{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }
catch(Exception exc)
{ exc.printStackTrace(); }
}




*******************************************************************************************************************************************************

The scenario that works:

The variation of the test, RMIIOPFOTC4A

1. Start Cluster with 5 instances
2. Create 12 InitialContext with endpoint properties in the argument in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see load distributed across all instances in the cluster (correct behavior)

Test code is as follows


/// When we run appclient, we provide test id as RMIIIOPFOTC4A, this creates 12 ic and 12 sfsb remote ref
if(testid.equals("RMIIIOPFOTC4A"))
{
for(int i=0;i<12;i++)
{ client.createContextForStandalone(); client.createSFSBRemoteRef(); }
System.out.println("Test Passed");
}

//// This is how createContextForStandalone

public void createContextForStandalone()
{
try
{ myEnv = new InitialContext(properties); }
catch(Exception exc)
{ System.err.println("Caught an unexpected exception!"); exc.printStackTrace(); }
}



///// This is how createSFSBRemoteRef is done ( its same as scenario when test fails)

public void createSFSBRemoteRef()
{
try
{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }

catch(Exception exc)

{ exc.printStackTrace(); }

}

Here is how to deploy
asadmin --user admin deploy --retrieve /export/DecCVS/agentrepo//appclient --availabilityenabled=true --target st-cluster --force=true RMIIIOPFailover.ear

appclient execution
/export/DecCVS/glassfish3/glassfish/bin/appclient -Dcom.sun.appserv.iiop.endpoints=hat2k1.us.oracle.com:23700,hat2k1.us.oracle.com:23701,hat2k2.us.oracle.com:23700,hat2k2.us.oracle.com:23701,hat2k2.us.oracle.com:23702 -client /export/DecCVS/agentrepo/appclient/RMIIIOPFailoverClient/rmi-iiop-client2Client.jar -mainclass samples.rmiiiopclient.client.ACC_Standalone_Client



 Comments   
Comment by gopaljorapur [ 01/Feb/11 ]

This is important and should be fixed for 3.1

Comment by Ken Cavanaugh [ 03/Feb/11 ]

How bad is its impact? (Severity)
Regression in IIOP FOLB from GF 2.1.

How often does it happen? (Frequency)
Happens all the time in Gopal's test scenario.
It fails because LB happens to only one instance.

How much effort is required to fix it?
I have a proposed fix in the GF naming code (still discussing this with Mahesh and Marina).
The fix is to make sure that the JavaURLContext for java:comp/env/ejb has the correct
SerialContext.

What is the risk of fixing it? (Risk)
Low. Only FOLB is affected.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
The end user can avoid using java:comp/env/ejb. I'm not sure whether that is reasonable.

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

How long has the bug existed in the product?
Since the beginning of GF 3.1 FOLB development (roughly 6 months)

Do regression tests exist for this issue?
No FOLB dev test (I haven't been able to set this up), but there is an SQE test.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
IIOP FOLB SQE tests

When will a tested fix be ready for integration?
Probably later today (2/3/11)

Comment by Ken Cavanaugh [ 03/Feb/11 ]

Fixed in rev 44898.





[GLASSFISH-15679] There are unlocalized strings in the JMS Physical Destinations Page Created: 25/Jan/11  Updated: 16/May/11  Resolved: 25/Jan/11

Status: Closed
Project: glassfish
Component/s: packaging
Affects Version/s: None
Fix Version/s: 3.1_ms08

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

Server OS: RHEL 5
Bundle: glassfish-3.1-b39-01_24_2011-unix-ml.sh
Build: 3.1_b39
Locales: ko, zh_CN


Attachments: JPEG File JMSPhysical_unloca.jpg    
Tags: 3_1-approved

 Description   

There are unlocalized strings in the JMS Physical Destinations Page

To reproduce:
1. Login to Admin Console.
2. Go to Server -> JMS Physical Destinations.

There are unlocalized strings in the JMS Physical Destinations Page. But it is okay in the bundle ogs-3.1-b39-01_24_2011-windows-ml.exe. Pls find the screen shot for your reference.



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

I have verified that the page is going through the String key to get the title and title help.

<sun:title id="propertyContentPage" title="$resource

{i18njms.jmsPhysDestinations.pageTitle}

" helpText="$resource

{i18njms.jmsPhysDestinations.pageHelp}

"/>

You are already using the latest nightly build, glassfish-3.1-b39-01_24_2011-unix-ml.sh and still see the issue. I am going to transfer to i18n for investigation.

Comment by gmurr [ 25/Jan/11 ]

It seems glassfish-jms-l10n is not installed

Comment by Snjezana Sevo-Zenzerovic [ 25/Jan/11 ]

How bad is its impact? (Severity)

  • Impact on users of ML distributions - parts of Admin console will not be localized.

How often does it happen? (Frequency)

  • For all ML Open Source Edition users.

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

  • Minimal. One extra l10n package needs to be installed during ML install image assembly.

What is the risk of fixing it? (Risk)

  • Minimal. OGS distribution assembly already contains the fix.

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

  • Workaround would be to manually install missing l10n package from UC.

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

  • Yes.
Comment by Chris Kasso [ 25/Jan/11 ]

Approved for 3.1

Comment by Snjezana Sevo-Zenzerovic [ 25/Jan/11 ]

Fix checked in:

Index: glassfish-distributions.xml
===================================================================
— glassfish-distributions.xml (revision 44703)
+++ glassfish-distributions.xml (working copy)
@@ -3,7 +3,7 @@

DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

  • Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
    + Copyright (c) 2010-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
@@ -180,6 +180,10 @@
<property name="image.dir" value="$

{image.dir}"/>
</ant>
<ant antfile="../distributions.xml" target="install-package">
+ <property name="package.name" value="glassfish-jms-l10n"/>
+ <property name="image.dir" value="${image.dir}

"/>
+ </ant>
+ <ant antfile="../distributions.xml" target="install-package">
<property name="package.name" value="mq-locale"/>
<property name="image.dir" value="$

{image.dir}

"/>
</ant>

Sending glassfish/glassfish-distributions.xml
Transmitting file data .
Committed revision 44705.

Comment by sunny-gui [ 16/May/11 ]

verified and fixed in gf 3.1.1 build 4.





[GLASSFISH-15678] fileRealm creation fails on windows when absolute path to keyfile is specified. Created: 24/Jan/11  Updated: 11/Mar/11  Resolved: 11/Mar/11

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

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

OS: Windows 2008 server.
browser: IE 7, and firefox 3.6


Tags: 3-1_next, 3_1-exclude

 Description   

GF Build used : promoted b38.
In Windows while creating a fileRealm, under server-config/security/, if we give the path to the keyfile as C:\glassfish\glassfish\domains\domain1\config\keyfile, the creation of the realm fails with below Error:
ErrorAn error has occurred
Invalid property syntax, missing property value: \glassfish\glassfish\domains\domain1\config\keyfile

The C: is not considered and below error is seen, and also in the screen rendered does not list the keyfile field, so that we can correct the path. we have to always open a "new realm" window by going to the realms table.

The auth realm creation succeeds only if we give the path as below:
$

{com.sun.aas.instanceRoot}

/config/keyfile



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

We probably need to escape ":" when passing in the property value.

Comment by srinik76 [ 24/Jan/11 ]

How bad is its impact? (Severity)
Severe. This page is completely unusable after the page fails because of property without escape sequenced

How often does it happen? (Frequency)
It happens in Windows if key file contains colon

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

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

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
User needs to escape sequence the text while entering, this cannot be expected from the user

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
It can be release noted but the workaround is difficult for the user to manipulate and enter it

Comment by srinik76 [ 25/Jan/11 ]

Requesting GUI team to review

Index: src/main/java/org/glassfish/admingui/common/handlers/SecurityHandler.java
===================================================================
— src/main/java/org/glassfish/admingui/common/handlers/SecurityHandler.java (revision 44697)
+++ src/main/java/org/glassfish/admingui/common/handlers/SecurityHandler.java (working copy)
@@ -299,7 +299,10 @@
String propertyStr ="";
for(Map oneProp: propList)

{ propertyStr = propertyStr + oneProp.get("name") + "="; - propertyStr = propertyStr + oneProp.get("value") + ":"; + String value = (String) oneProp.get("value"); + value = value.replaceAll("\\\\", "\\\\\\\\"); + value = UtilHandlers.escapePropertyValue(value); + propertyStr = propertyStr + value + ":"; }

endpoint = endpoint + "/auth-realm";
cMap.put("target", attrMap.get("target"));

Comment by Chris Kasso [ 25/Jan/11 ]

Approved for 3.1

Comment by srinik76 [ 26/Jan/11 ]

Sending src/main/java/org/glassfish/admingui/common/handlers/SecurityHandler.java
Transmitting file data .
Committed revision 44732.

Comment by shaline [ 08/Feb/11 ]

This issue is fixed in server-config. But in other configs (local or remote instance config ), I see the below error in the screen while trying to create a fileRealm and when absolute path to config file is specified for Windows.

An error has occurred
An error occurred during replication

Steps:
Create a new config by copying from default-config.
Create a file realm , and for the keyfile specify the absolute path as below :C:\glassfish-install\glassfish\domains\domain1\config\keyfile

When we click Save button, the above error is displayed.
But actually the realm is created even with the above error. The above error is misleading.

Server.log has the below Exception.:

[#|2011-02-08T15:47:04.057-0800|SEVERE|oracle-glassfish3.1|org.glassfish.admingu
i|_ThreadID=104;_ThreadName=Thread-1;|RestResponse.getResponse() gives FAILURE.
endpoint = 'https://localhost:4848/management/domain/configs/config/ins1-config/security-service/auth-realm'; attrs = '

{classname=com.sun.enterprise.security.auth.realm.file.FileRealm, name=newrealm, target=ins1-config, property=file=C\:\\SQE\\V3.1\\glassfish\\glassfish\\domains\\domain1\\config\\keyfile:jaas-context=fileRealm:}

'|#]

[#|2011-02-08T15:47:04.386-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.syst
em.std.com.sun.enterprise.server.logging|_ThreadID=14098;_ThreadName=Thread-1;|javax.el.PropertyNotFoundException: java.lang.IndexOutOfBoundsException: Index: 0
, Size: 0 at com.sun.webui.jsf.faces.DataProviderELResolver$ValueData.getValue(DataProviderELResolver.java:413)
at com.sun.webui.jsf.faces.DataProviderELResolver.getValue(DataProviderELResolver.java:159)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:116)
at com.sun.el.parser.AstValue.getValue(AstValue.java:163)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:219)
at com.sun.webui.jsf.component.TableRowGroup.isSelected(TableRowGroup.java:2979)
at com.sun.webui.jsf.renderkit.html.TableRowGroupRenderer.renderEnclosingTagStart(TableRowGroupRenderer.java:762)
at com.sun.webui.jsf.renderkit.html.TableRowGroupRenderer.encodeChildren(TableRowGroupRenderer.java:187)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at com.sun.webui.jsf.util.RenderingUtilities.renderComponent(RenderingUtilities.java:91)
at com.sun.webui.jsf.renderkit.html.TableRenderer.encodeChildren(TableRenderer.java:168)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at com.sun.webui.jsf.util.RenderingUtilities.renderComponent(RenderingUtilities.java:91)
at com.sun.webui.jsf.renderkit.html.TableRenderer.encodeChildren(TableRenderer.java:168)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:551)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:555)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.encode(LayoutComponent.java:243)
at com.sun.jsftemplating.layout.descriptors.LayoutInsert.encodeChildren(LayoutInsert.java:125)
at com.sun.jsftemplating.layout.descriptors.LayoutInsert.encodeThis(LayoutInsert.java:107)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:330)
at com.sun.jsftemplating.layout.descriptors.LayoutComposition.encodeThis
(LayoutComposition.java:161)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:330)
at com.sun.jsftemplating.layout.descriptors.LayoutComposition.encodeThis(LayoutComposition.java:161)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:330)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutDefinition.encode(LayoutDefinition.java:246)
at com.sun.jsftemplating.layout.LayoutViewHandler.renderView(LayoutViewHandler.java:683)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
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.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:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
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.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at com.sun.jsftemplating.component.dataprovider.MultipleListDataProvider.getObject(MultipleListDataProvider.java:130)
at com.sun.jsftemplating.component.dataprovider.MultipleListDataProvider.getSupport(MultipleListDataProvider.java:564)
at com.sun.jsftemplating.component.dataprovider.MultipleListDataProvider.getFieldKey(MultipleListDataProvider.java:260)
at com.sun.data.provider.impl.TableRowDataProvider.getFieldKey(TableRowDataProvider.java:113)
at com.sun.webui.jsf.faces.DataProviderELResolver$ValueData.getValue(DataProviderELResolver.java:399)
... 60 more

#]
Comment by Anissa Lam [ 08/Feb/11 ]

As you mentioned,
"When we click Save button, the above error is displayed.
But actually the realm is created even with the above error. The above error is misleading. "

Error msg shows up wrongly, even though realm is created.
Will look into this for 3.2.

Comment by srinik76 [ 11/Mar/11 ]

Tested with the latest build checked out from the workspace. Tried creating in windows, new file realm in new-config copied from default-config with key file as mentioned in the latest bug update.

It works fine without any error. So closing the bug.





[GLASSFISH-15666] remove commented grants from server.policy Created: 24/Jan/11  Updated: 24/Jan/11  Resolved: 24/Jan/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: 3.1_ms08

Type: Bug Priority: Minor
Reporter: kumarjayanti Assignee: kumarjayanti
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved

 Description   

When the cleanup of grants in sever.policy was done for V3.1, we had commented the irrelevant ones instead of deleting. This was done because i wanted to be sure none of them would really be required. Now that we are close to a release and all testing is nearly done, it is clear that those grants can be removed.

SVN diff of the change:
-----------------

Index: lib/templates/server.policy
===================================================================
— lib/templates/server.policy (revision 44678)
+++ lib/templates/server.policy (working copy)
@@ -53,76 +53,17 @@
permission java.security.AllPermission;
};

-// jdmk classes get all permissions by default
-//grant codeBase "file:$

{com.sun.aas.jdmkHome}

/lib/-"

{ -// permission java.security.AllPermission; -//};
-
-// mfwk_instrum_tk.jar get all permissions by default
-//grant codeBase "file:${com.sun.aas.mfwkHome}/lib/mfwk_instrum_tk.jar" {-// permission java.security.AllPermission;-//}

;
-
-// lockhart classes get all permissions by default
-//grant codeBase "file:$

{com.sun.aas.webconsoleLib}

/cc.jar"

{ -// permission java.security.AllPermission; -//};
-
-// jato classes get all permissions by default
-//grant codeBase "file:${com.sun.aas.jatoRoot}/jato.jar" {-// permission java.security.AllPermission;-//}

;
-
-// JBI get all permissions by default
-//grant codeBase "file:$

{com.sun.aas.installRoot}

/jbi/-"

{ -// permission java.security.AllPermission; -//};
-
-// JBI instances get all permissions by default
//grant codeBase "file:${com.sun.aas.instanceRoot}/jbi/" {-// permission java.security.AllPermission;-//}

;
-
-// Composite applications get all permissions by default
-//grant codeBase "file:$

{com.sun.aas.instanceRoot}

/applications/composite-applications/-"

{ -// permission java.security.AllPermission; -//};
-
// iMQ classes get all permissions by default
grant codeBase "file:${com.sun.aas.imqLib}/-" { permission java.security.AllPermission; };

-// ANT classes get all permissions by default
//grant codeBase "file:${com.sun.aas.antLib}/" {-// permission java.security.AllPermission;-//}

;
-
// Derby driver classes get all permissions by default
grant codeBase "file:$

{com.sun.aas.derbyRoot}

/lib/-"

{ permission java.security.AllPermission; }

;

-// Pointbase embedded server classes get all permissions by default
-//grant codeBase "file:$

{com.sun.aas.pointbaseRoot}

/lib/-"

{ -// permission java.security.AllPermission; -//};

-// Web Services classes get all permissions by default
//grant codeBase "file:${com.sun.aas.webServicesLib}/" {-// permission java.security.AllPermission;-//}

;
-
-// permissions for avkit classes
-//grant codeBase "file:$

{j2ee.appverification.home}

/lib/-"

{ -// permission java.security.AllPermission; -//};
-
-// permissions for HADB jar file(s)
//grant codeBase "file:${com.sun.aas.hadbRoot}/lib/" {-// permission java.security.AllPermission;-//}

;
-
// permission for JDK's tools.jar to enable webservice annotation processing
// at runtime by wsgen tool:
// permission java.lang.RuntimePermission "createClassLoader";



 Comments   
Comment by kumarjayanti [ 24/Jan/11 ]

1. How bad is its impact? (Severity)
Minor (not a bug). The idea is to remove some clutter from server.policy in terms of removing commented grants.

2. How often does it happen? (Frequency)
Not a bug

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

4. What is the risk of fixing it? (Risk)
No Risk

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

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

Comment by Chris Kasso [ 24/Jan/11 ]

Approved for 3.1

Comment by kumarjayanti [ 24/Jan/11 ]

fixed





[GLASSFISH-15635] [UB]Show "restart required" status when a new resource is created or deleted Created: 20/Jan/11  Updated: 11/Apr/11  Resolved: 08/Apr/11

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

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

Attachments: PDF File config-changes.pdf    

 Description   

Per "Impact of Configuration Changes" section of Admin Guide, Configuration Changes That Require Server Restart include: Creating or deleting resources.

However, "restart required" is not indicated by Admin CLI/GUI when a new resource is created or deleted.

Example Steps:

Create / Delete new JNDI resource on Admin Console.

Click Resources - JNDI - Custom Resources - new -
JNDI Name: testJNDI
Resorce Type: java.util. Properties
Factory Class: org.glassfish.resources.custom.factory.PropertiesFactory
Status: Enabled
Target: Select All (C1, Server)

  • Save

Expected: Restart Required notification is displayed.

  • Delete the resource testJNDI.

Expected: Restart Required notification is displayed.

Results:
$ asadmin list-domains
domain1 running
======================



 Comments   
Comment by Jagadish [ 24/Jan/11 ]

None of the resources/pools when re-configured mandates restart.

  • Application(s) that use the resources/pools need to be disabled and enabled
    or
  • Application(s) that use the resources/pools need to be re-deployed

Only when the user does not know the application(s) list that use the resources/pools, server restart is required.

Please remove the following line from Administration Guide:
http://download.oracle.com/docs/cd/E19226-01/820-7692/gitzw/index.html

"Creating or deleting resources (Exception: Some JDBC, JMS, or connector resources do not require restart.)"

Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Paul Davies [ 08/Apr/11 ]

Fix attached for verification purposes. The fix will be delivered in the next update of the all-in-one documentation bundle.

Comment by Harshad Vilekar [ 11/Apr/11 ]

Verified the updated doc attachment.





[GLASSFISH-15630] NPE in MasterPasswordImpl Created: 20/Jan/11  Updated: 22/Jan/11  Due: 24/Jan/11  Resolved: 22/Jan/11

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

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

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

 Description   

Given a v2.1.1 domain (updomain.zip from the admin dev tests framework), this works:

asadmin start-domain --upgrade updomain
asadmin start-domain updomain

But if I start the domain without the upgrade first, the server sees that it's an older domain, performs the upgrade, and continues to start the server in normal mode. That leads to this NPE and asadmin returns with a failure message:

[#|2011-01-20T15:37:41.408-0500|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=main;|Exception in thread "main" |#]

[#|2011-01-20T15:37:41.413-0500|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=main;|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.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.security.ssl.impl.MasterPasswordImpl.setMasterPassword(MasterPasswordImpl.java:68)
at com.sun.enterprise.v3.admin.IdmService.postConstruct(IdmService.java:114)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:128)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:88)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:79)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:64)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:136)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:219)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
... 6 more

#]

Since there is a workaround (run with --upgrade first), I don't think this needs to be fixed in 3.1 given where we are. But I wanted to make sure the issue is known.



 Comments   
Comment by Bobby Bissett [ 20/Jan/11 ]

Actually, I see this now when starting a v3 prelude domain as well, which isn't supposed to require an upgrade. So this may be more important to fix than I thought.

Comment by kumarjayanti [ 20/Jan/11 ]

Can you attach a v3 prelude domain or tell me the link to obtain it.

Comment by kumarjayanti [ 21/Jan/11 ]

1. How bad is its impact? (Severity)
NPE if an old domain (V2.X or V3-prelude) is used without the --upgrade.

2. How often does it happen? (Frequency)
Upgrade only and is not a problem when --upgrade is run first (according to bobby)

3. How much effort is required to fix it? (Cost)
The fix is easy, two methods are returning boolean status true without checking if masterPassword is finally set to non-null value.

4. What is the risk of fixing it? (Risk)
No Risk

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
according to Bobby who has filed this issue the workaround is to make sure --upgrade is run first.

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

Comment by Bobby Bissett [ 21/Jan/11 ]

Sure, here's a download link:
http://download.java.net/glassfish/v3-prelude/release/glassfish-v3-prelude.zip

I've had this zip sitting around for ~1.5 years, but I verified that the above link is the same as my zip and that the problem happens with it.

Comment by Chris Kasso [ 21/Jan/11 ]

Approved for 3.1

Comment by kumarjayanti [ 22/Jan/11 ]

fixed





[GLASSFISH-15629] [UB]Show "restart required" status when JDBC connection pool properties are changed Created: 20/Jan/11  Updated: 11/Apr/11  Resolved: 08/Apr/11

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

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


 Description   

Per Admin Guide, you must restart the server for the changes in following properties to take effect:

JDBC connection pool properties:

1. datasource-classname
2. associate-with-thread
3. lazy-connection-association
4. lazy-connection-enlistment
5. JDBC driver vendor-specific properties

Test: Use Admin GUI to change values of above JDBC connection Pool properties:
Resource - JDBC - JDBC Connection Pools - Derby Pool - Advanced

Result: "restart required" is not indicated by Admin CLI/GUI after the changes to these properties are saved.

$ asadmin list-domains
domain1 running

Similar issue: http://java.net/jira/browse/GLASSFISH-15619



 Comments   
Comment by Jagadish [ 22/Jan/11 ]

Docs changes in "deployment guide" is in-place.
http://wikis.sun.com/display/GlassFish/GlassFishV3.1DeploymentDocReview
Please refer the comment by id "jagadish-6"

Docs changes are needed in "Administration Guide" > "Configuration changes that require restart".

Sub-section :
"Modifying the following JDBC connection pool properties"

We need to add a foot-note :

It is not always required to restart the server for changing any of these connection pool attributes or properties.
After re-configuring of the pool, user can disable and enable application(s) that use the pool or redeploy the application(s) that use the pool.
Only when application(s) that refer the pool is not known to the administrator or user, server restart is needed so that application(s) can use the re-configured pool.

Transferring to docs category for required changes.

Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Paul Davies [ 08/Apr/11 ]

To verify the fix, see the attachment to GLASSFISH-15635

Comment by Harshad Vilekar [ 11/Apr/11 ]

Verified the updated doc attachment.





[GLASSFISH-15627] Exception after failover with clusterjsp Created: 20/Jan/11  Updated: 20/Jan/11  Due: 21/Jan/11  Resolved: 20/Jan/11

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

Type: Bug Priority: Major
Reporter: Mahesh Kannan Assignee: Rajiv Mordani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File clusterjsp.ear    
Tags: 3_1-approved

 Description   

I see the following exception after failover with clusterjsp in a 2 instance cluster.

This exception occurs ONLY in a two instance cluster setup. The replication layer finds the data but the web container encounters the following exception:

[#|2011-01-20T10:03:30.022-0800|SEVERE|glassfish3.1|org.apache.catalina.connector.CoyoteAdapter|_ThreadID=30;_ThreadName=Thread-1;|PWC3989: An exception or error occurred in the container during the request processing
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:394)
at org.apache.catalina.session.StandardSession.setNote(StandardSession.java:1008)
at org.glassfish.web.ha.session.management.HASessionStoreValve.invoke(HASessionStoreValve.java:120)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
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:619)

Steps to reproduce

1. create a two instance cluster

2. access instance1 (http://localhost:18080/clusterjsp/HaJsp.jsp) and add a few attributes

3. stop instance 1

4. Access instance 2 (http://localhost:28080/clusterjsp/HaJsp.jsp)

You will see the above exception



 Comments   
Comment by Mahesh Kannan [ 20/Jan/11 ]

clusterjsp.ear

Comment by Rajiv Mordani [ 20/Jan/11 ]

How bad is its impact? (Severity)
Any 2 instance cluster will see this if one instance goes down.

How often does it happen? (Frequency)
In a 2 instance cluster if one instance goes down you will always see this.

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?
N/A.

Fix for the issue. Reviewed by Shing Wai and Mahesh :

Index: src/main/java/org/glassfish/web/ha/session/management/HASessionStoreValve.java
===================================================================
— src/main/java/org/glassfish/web/ha/session/management/HASessionStoreValve.java (revision 44626)
+++ src/main/java/org/glassfish/web/ha/session/management/HASessionStoreValve.java (working copy)
@@ -115,9 +115,11 @@
}
}
String replica = manager.getReplicaFromPredictor(sessionId, oldJreplicaValue);

  • Session sess = request.getSessionInternal(false);
  • if (sess != null) {
  • sess.setNote(Globals.JREPLICA_SESSION_NOTE, replica);
    + if (replica != null)
    Unknown macro: {+ Session sess = request.getSessionInternal(false);+ if (sess != null) { + sess.setNote(Globals.JREPLICA_SESSION_NOTE, replica); + } }

    }
    }
    Index: src/main/java/org/glassfish/web/ha/session/management/BaseHASession.java
    ===================================================================

      • src/main/java/org/glassfish/web/ha/session/management/BaseHASession.java (revision 44626)
        +++ src/main/java/org/glassfish/web/ha/session/management/BaseHASession.java (working copy)
        @@ -88,7 +88,9 @@
        // Set the jreplica value for the first request here when the session is created - after that it is done in the valve
        ReplicationManagerBase manager = (ReplicationManagerBase)(getManager());
        String jReplicaValue = manager.getReplicaFromPredictor(id, null);
  • setNote(Globals.JREPLICA_SESSION_NOTE, jReplicaValue);
    + if (jReplicaValue != null) { + setNote(Globals.JREPLICA_SESSION_NOTE, jReplicaValue); + }
Comment by Chris Kasso [ 20/Jan/11 ]

Approved for 3.1





[GLASSFISH-15619] [UB]show "restart required" status when connector connection pool properties are changed Created: 19/Jan/11  Updated: 11/Apr/11  Resolved: 08/Apr/11

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

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


 Description   

Similar to: http://java.net/jira/browse/GLASSFISH-15516

Per admin guide, domain restart is required when following connector connection pool properties are modified:

----------------------------
1. resource-adapter-name
2. connection-definition-name
3. transaction-support
4. associate-with-thread
5. lazy-connection-association
6. lazy-connection-enlistment
7. Vendor-specific properties
----------------------------

Updating any of these properties doesn't show "restart-required" on Admin Console / CLI.

$ asadmin list-domains
domain1 running

Example Steps:

1. Create new connector connection pool on Admin Console:

Resources - Connector - Connector Connection Pool - New :

Pool Name : myConnectionPool
Resource Adapter : jmsra (select from pull down menu)
Connection Definition: javax.jms.ConnectionFactory (select from pull down menu)

click Next

Leave everything else default, click Finish

2. Edit myConnectionPool General Properties

  • Click on myConnecitonPool
  • General Tab:

Connection Definition: javax.jms.QueueConnectionFactory

Transaction Support: XATransaction

  • Click Save

Expected: "restart required" is shown
===================



 Comments   
Comment by Jagadish [ 19/Jan/11 ]

There was a docs issue to change the description for the reconfiguration of these attributes.
"Restart required" is a hard requirement and is not always necessary.

Any of the following actions will also work.

1) Applications that refer the resource/pool can be re-deployed
2) Applications that refer the resource/pool can be disabled and then enabled (re-enabled)
3) Only when some-one does not know which applications are using the resource, restart is required so that the applications can start using re-configured resource/pool.

I have requested for the above docs changes and is made available now :
http://wikis.sun.com/display/GlassFish/GlassFishV3.1DeploymentDocReview

Comment by Jagadish [ 19/Jan/11 ]

Marking this as not an issue as "Restart required" is not always needed.

Comment by Harshad Vilekar [ 20/Jan/11 ]

It's important to show "restart required" indication, when listed connector connection pool properties are changed - so that the user is aware that the changes are not yet effective.

Updated Deployment Guide, Page 130 says: "Changing the following attributes (listed in a table c-36) 'requires a server restart' or the redeployment or disabling and re-enabling of applications... "

Admin Guide also says that the server must be restarted for changes in listed connector connection pool properties to take effect.

Reopening the issue - Approved by Nazrul.

Comment by Jagadish [ 22/Jan/11 ]

Docs changes in "deployment guide" is in-place.
http://wikis.sun.com/display/GlassFish/GlassFishV3.1DeploymentDocReview
Refer the comment by id "jagadish-7"

Docs changes are needed in "Administration Guide" > "Configuration changes that require restart".

Sub-section :
"Modifying the following connector connection pool properties"

We need to add a foot-note :

It is not always required to restart the server for changing any of these connection pool attributes or properties.
After re-configuring of the pool, user can disable and enable application(s) that use the pool or redeploy the application(s) that use the pool.
Only when application(s) that refer the pool is not known to the administrator or user, server restart is needed so that application(s) can use the re-configured pool.

Transferring to docs category for required changes.

Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Paul Davies [ 08/Apr/11 ]

To verify the fix, see the attachment to GLASSFISH-15635

Comment by Harshad Vilekar [ 11/Apr/11 ]

Verified the updated doc attachment.





[GLASSFISH-15613] [UB] property to tune buffer size for in-memory replication Created: 19/Jan/11  Updated: 20/Apr/11  Resolved: 20/Apr/11

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

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


 Description   

[Tracking Bug]

We have a property that is being used to tune buffer size for in-memory replication. Depending on the session size and load, this property needs to be adjusted. Please document this in performance tuning guide and HA guide .

Mahesh will be able to provide the name of the property and other details.



 Comments   
Comment by Mahesh Kannan [ 10/Feb/11 ]

The replication batch size can be tuned by setting the System property "org.shoal.cache.transmitter.max.batch.size" to a non negative number.

Example: org.shoal.cache.transmitter.max.batch.size=20 The default is 30.

Comment by Scott Fordin [ 11/Feb/11 ]

No Performance Tuning Guide anymore. Will add content to HAAG. If appropriate, will also add content to Performance Tuner OLH.

Comment by Scott Fordin [ 21/Mar/11 ]

We do have a Performance Tuning Guide after all, and I'd like to add these instructions to that guide with additional links to the GMS sections in the HA Admin Guide. However, I need additional instructions on how to set this property. I tried doing:

asadmin> set configs.config.cluster1-config.group-management-service.org.shoal.cache.transmitter.max.batch.size=20

But got:

remote failure: No configuration found for configs.config.cluster1-config.group-management-service.org.shoal.cache.transmitter.max.batch
Command set failed.

As a starting point, I tried using the instructions in To Preconfigure Nondefault GMS Configuration Settings (http://download.oracle.com/docs/cd/E18930_01/html/821-2426/gjfnl.html#gkoac), but they didn't help.

Can you please provide additional information?

Comment by Scott Fordin [ 20/Apr/11 ]

Worked with Mahesh and added content to 3.1 Performance Tuning Guide.





[GLASSFISH-15611] [UB] relaxCacheVersionSemantics property for in-memory replication Created: 19/Jan/11  Updated: 22/Mar/11  Resolved: 22/Mar/11

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

Type: Task Priority: Major
Reporter: Nazrul Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Please document relaxCacheVersionSemantics property in HA guide

Reference:
Blog: http://blogs.sun.com/memrep/entry/memory_replication_multi_threaded_concurrent
Example Issue: http://java.net/jira/browse/GLASSFISH-14028



 Comments   
Comment by Scott Fordin [ 22/Mar/11 ]

Added new Configuring Replication and Multi-Threaded Concurrent Access to HttpSessions section to the Configuring High Availability Session Persistence and Failover chapter of the 3.1 HA Admin Guide.





[GLASSFISH-15602] [UB]Need update Documentaion for helping using to build and configure Apache with openssl for GlassFish 3.1 HA scenario Created: 18/Jan/11  Updated: 24/Mar/11  Resolved: 03/Mar/11

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

Type: Bug Priority: Major
Reporter: Homer Yau Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any supported platform


Tags: 3_1, glassfish, plugin, ssl

 Description   

Need to provide update documentation information for user to build and configure Apache with Openssl for GlassFish 3.1 HA scenario.

Currently, I have tested with SuSE and it seems to be working.
However, when try to build on Solaris Sparc and Solaris x86 using Apache http2.2.17 and openssl-1.0.0a and it failed during "make".

We need update documentation to help user to build apache with ssl support for lbconfigurator to install LBplugin for GlassFish 3.1 to have HA scenario.

Here is the error after ./configure and ./make.

bash-3.00# ./configure --with-ssl=/usr/local/openssl --prefix=/export/ha/apache2.2 --enable-ssl --enable-so --with-included-apr
......

bash-3.00# make
Making all in srclib
Making all in apr
Making all in apr-util
Making all in pcre
Making all in os
Making all in unix
Making all in server
Making all in mpm
Making all in prefork
Making all in modules
Making all in aaa
Making all in filters
Making all in loggers
Making all in metadata
Making all in ssl
Making all in http
Making all in generators
Making all in mappers
Making all in support
/export/ha/downloads/APACHE_STUFF/httpd-2.2.17/srclib/apr/libtool --silent --mode=link gcc -m32 -L/usr/local/openssl/lib -R/usr/local/openssl/lib -L/usr/sfw/lib -L/usr/lib -o ab ab.lo -lm /export/ha/downloads/APACHE_STUFF/httpd-2.2.17/srclib/pcre/libpcre.la /export/ha/downloads/APACHE_STUFF/httpd-2.2.17/srclib/apr-util/libaprutil-1.la -lexpat /export/ha/downloads/APACHE_STUFF/httpd-2.2.17/srclib/apr/libapr-1.la -luuid -lsendfile -lrt -lsocket -lnsl -lpthread -lssl -lcrypto -lsocket -lnsl -ldl
Undefined first referenced
symbol in file
BIO_set_callback .libs/ab.o
BIO_set_callback_arg .libs/ab.o
BIO_get_callback_arg .libs/ab.o
SSL_CTX_set_info_callback .libs/ab.o
ld: fatal: Symbol referencing errors. No output written to .libs/ab
collect2: ld returned 1 exit status

      • Error code 1
        make: Fatal error: Command failed for target `ab'
        Current working directory /export/ha/downloads/APACHE_STUFF/httpd-2.2.17/support
      • Error code 1
        The following command caused the error:
        otarget=`echo all-recursive|sed s/-recursive//`; \
        list=' '; \
        for i in $list; do \
        if test -d "$i"; then \
        target="$otarget"; \
        echo "Making $target in $i"; \
        if test "$i" = "."; then \
        made_local=yes; \
        target="local-$target"; \
        fi; \
        (cd $i && make $target) || exit 1; \
        fi; \
        done; \
        if test "$otarget" = "all" && test -z 'htpasswd htdigest rotatelogs logresolve ab checkgid htdbm htcacheclean httxt2dbm'; then \
        made_local=yes; \
        fi; \
        if test "$made_local" != "yes"; then \
        make "local-$otarget" || exit 1; \
        fi
        make: Fatal error: Command failed for target `all-recursive'
        Current working directory /export/ha/downloads/APACHE_STUFF/httpd-2.2.17/support
      • Error code 1
        The following command caused the error:
        otarget=`echo all-recursive|sed s/-recursive//`; \
        list=' srclib os server modules support'; \
        for i in $list; do \
        if test -d "$i"; then \
        target="$otarget"; \
        echo "Making $target in $i"; \
        if test "$i" = "."; then \
        made_local=yes; \
        target="local-$target"; \
        fi; \
        (cd $i && make $target) || exit 1; \
        fi; \
        done; \
        if test "$otarget" = "all" && test -z 'httpd '; then \
        made_local=yes; \
        fi; \
        if test "$made_local" != "yes"; then \
        make "local-$otarget" || exit 1; \
        fi
        make: Fatal error: Command failed for target `all-recursive'


 Comments   
Comment by Homer Yau [ 04/Feb/11 ]

For compile openssl-1.0.0a or openssl-1.0.0c

For Solaris Sparc build:
========================
[1] solaris-sparcv9-gcc

Use the above option when compiling openssl on sparc

You need run for openssl -
./Configure [--prefix=DIR] [--openssldir=OPENSSLDIR] -m32 [1]
make
make install

Here are my steps for Linux distribution:
=========================================

Build Apache and OpenSSL
=====================
rm -rf openssl-1.0.0c httpd-2.2.17
gzip -dc openssl-1.0.0c.tar.gz | tar -xvof -
gzip -dc httpd-2.2.17.tar.gz | tar -xvof -

I am taking default location to build both Apache and OpenSSL.

1) Build OpenSSL
cd openssl-1.0.0c
./Configure linux-generic32 -m32
make
make install

2) Build Apache
export CFLAGS="-m32"
./configure --prefix=/export/ha/apache2.2 --enable-ssl --with-ssl=/usr/local/ssl --enable-so --with-included-apr
make
make install

Create SelfSign Certificate ( only for testing or internal use)
===========================================
openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

cp server.crt /export/ha/apache2.2/conf/.
cp server.key /export/ha/apache2.2/conf/.

Edit <apache2.2_install_dir>/conf/httpd.conf (if require for the ServerName)
Edit <apache2.2_install_dir>/conf/extra/httpd-ssl.conf (if require for the ServerName)

Check the information in <apache2.2_install_dir>/conf/extra/httpd-vhosts.conf (if require)

Export DAS certificate
=================
Prepare for LBPlugin installation use.
keytool -export -rfc -alias s1as -keystore keystore.jks -file s1as.rfc

Load Balancer Configurator installation
=============================
java -jar glassfish-lbconfigurator-3_1-b05.jar

Both openssl and httpd are "ELF 32-bit LSB executable".

[root@dragonfish downloads]# file /usr/local/ssl/bin/openssl
/usr/local/ssl/bin/openssl: ELF 32-bit LSB executable, Intel 80386, version 1 (S
YSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

[root@dragonfish downloads]# file /export/ha/apache2.2/bin/httpd
/export/ha/apache2.2/bin/httpd: ELF 32-bit LSB executable, Intel 80386, version
1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

Comment by Scott Fordin [ 03/Mar/11 ]

Instructions added to 3.1 HA Admin Guide.

Comment by Scott Fordin [ 24/Mar/11 ]

Topic was added to HA Admin Guide, so I've removed the release notes tag.





[GLASSFISH-15593] FindBugs issues in SerialInitContextFactory Created: 17/Jan/11  Updated: 18/Jan/11  Resolved: 18/Jan/11

Status: Resolved
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1_ms08
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

The automatic findbugs checker caught the following:

kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialInitContextFactory.java:260: NP_NULL_PARAM_DEREF: Method call in com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(Hashtable) passes null for nonnull parameter of propertyIsSet(Hashtable, String)
kcavanaugh: common/glassfish-naming/src/main/java/com/sun/enterprise/naming/impl/SerialInitContextFactory.java:258: NP_NULL_PARAM_DEREF: Method call in com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(Hashtable) passes null for nonnull parameter of propertyIsSet(Hashtable, String)

The fix is trivial: just change env to myEnv in the affected lines.

I am assuming that we have a blanket approval to fix findbugs issues.



 Comments   
Comment by Ken Cavanaugh [ 18/Jan/11 ]

FindBugs fix checked into rev 44544.





[GLASSFISH-15584] Messages from Grizzly Framework are logged under null logger Created: 14/Jan/11  Updated: 04/Mar/11  Resolved: 19/Jan/11

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: None
Fix Version/s: 3.1_ms08

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

build: b37


Attachments: File fix-15584.diff    
Tags: 3_1-approved, 3_1-regression, 3_1-verified

 Description   

Messages logged to server.log from Grizzly Framework are logged under null logger:

[#|2011-01-14T18:46:17.156-0800|INFO|oracle-glassfish3.1|null|_ThreadID=13;_Thre
adName=Thread-1;|Grizzly Framework 1.9.28 started in: 150ms - bound to [0.0.0.0:
7676]|#]

[#|2011-01-14T18:46:17.158-0800|INFO|oracle-glassfish3.1|null|_ThreadID=15;_Thre
adName=Thread-1;|Grizzly Framework 1.9.28 started in: 239ms - bound to [0.0.0.0:
8181]|#]

[#|2011-01-14T18:46:17.155-0800|INFO|oracle-glassfish3.1|null|_ThreadID=12;_Thre
adName=Thread-1;|Grizzly Framework 1.9.28 started in: 211ms - bound to [0.0.0.0:
4848]|#]

This regression has been introduced a while back. I can see that the logger was reported correctly in build b27:

[#|2011-01-14T14:47:30.439-0800|INFO|oracle-glassfish3.1|com.sun.grizzly.config.
GrizzlyServiceListener|_ThreadID=15;_ThreadName=Thread-1;|GRIZZLY0001: Starting
Grizzly Framework 1.9.21 - 1/14/11 2:47 PM|#]

[#|2011-01-14T14:47:30.506-0800|INFO|oracle-glassfish3.1|com.sun.grizzly.config.
GrizzlyServiceListener|_ThreadID=15;_ThreadName=Thread-1;|GRIZZLY0001: Starting
Grizzly Framework 1.9.21 - 1/14/11 2:47 PM|#]

[#|2011-01-14T14:47:30.554-0800|INFO|oracle-glassfish3.1|null|_ThreadID=15;_Thre
adName=Thread-1;|Grizzly Framework 1.9.21 started in: 206ms - bound to [0.0.0.0:
3700]|#]

Starting with Grizzly Framework 1.9.22 the logger is null.



 Comments   
Comment by oleksiys [ 19/Jan/11 ]

here is the fix I propose.
please approve it for integration.

Comment by Nazrul [ 19/Jan/11 ]

1. How bad is its impact? (Severity)

Is a regression of functionality
Introduces an incompatibility
Likely to generate a customer support call

2. How often does it happen? (Frequency)
During every log message from Grizzly

3. How much effort is required to fix it? (Cost)
Fix already available (1 line fix)

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

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

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

Comment by oleksiys [ 19/Jan/11 ]

Project: glassfish
Repository: svn
Revision: 44600
Author: oleksiys
Date: 2011-01-19 17:38:09 UTC
Link:

Log Message:
------------
+ fix issue #15584
http://java.net/jira/browse/GLASSFISH-15584

"Messages from Grizzly Framework are logged under null logger"

Approved by Nazrul

Revisions:
----------
44600

Modified Paths:
---------------
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyService.java

Comment by lidiam [ 04/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-15549] Dev Test Failure(s) Created: 12/Jan/11  Updated: 06/Jul/11  Due: 14/Jan/11  Resolved: 06/Jul/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-15444 Dev test failures Open
Tags: 3_1-review

 Description   

Per Nazrul's Email

Suma (10)

Failed tests:
[artifact:mvn] testMonitoringApplicationsPage(org.glassfish.admingui.devtests.MonitoringTest)
[artifact:mvn] testAdminObjectResources(org.glassfish.admingui.devtests.AdminObjectTest)

[artifact:mvn] Tests in error:
[artifact:mvn] testConnectorResourcesWithTargets(org.glassfish.admingui.devtests.ConnectorsTest)
[artifact:mvn] testJdbcResourcesWithTargets(org.glassfish.admingui.devtests.JdbcTest)
[artifact:mvn] testCustomResourcesWithTargets(org.glassfish.admingui.devtests.JndiTest)
[artifact:mvn] testExternalResourcesWithTargets(org.glassfish.admingui.devtests.JndiTest)
[artifact:mvn] testStandaloneInstanceResourcesPage(org.glassfish.admingui.devtests.StandaloneTest)
[artifact:mvn] createMailResourceWithTargets(org.glassfish.admingui.devtests.JavaMailTest)
[artifact:mvn] testMonitoringServerPage(org.glassfish.admingui.devtests.MonitoringTest)
[artifact:mvn] testAdminObjectResourcesWithTargets(org.glassfish.admingui.devtests.AdminObjectTest)



 Comments   
Comment by Nazrul [ 12/Jan/11 ]

Adding 3_1-review to exclude this from un-scrubbed list

Comment by sumasri [ 13/Jan/11 ]

These are the latest results from hudson.
Requesting Jason to comment on the below issues.

Failed tests:
[artifact:mvn] testAdminObjectResources(org.glassfish.admingui.devtests.AdminObjectTest)
[artifact:mvn] testAdminObjectResourcesWithTargets(org.glassfish.admingui.devtests.AdminObjectTest)
Fixed these 2 tests and checked in the code.

[artifact:mvn] testExternalResourcesWithTargets(org.glassfish.admingui.devtests.JndiTest)
This is working fine. It is giving inconsistent results.

[artifact:mvn] testMonitoringApplicationsPage(org.glassfish.admingui.devtests.MonitoringTest)
Will work on this.

[artifact:mvn] testResourceAdapterConfigs(org.glassfish.admingui.devtests.ResourceAdapterConfigsTest)
Issue: Resource Adapter config creation is taking a very long time if jms is already started.
Assumption : As per my understanding, we persist one property in domain.xml at a time.
Background work on the issue: While persisting each property, event will be notified and then it stops the jms and starts the jms. So, it is taking a very long time. Hence, the test is failing.
I think this issue can be resolved in REST side.Please let me know your comments on this.

There is one more issue with it . Once JMS is started and try to create a resource adpater config with http-thread-pool, it is throwing an exception. I will file the issue for the backend team.

[artifact:mvn] testMonitoringServerPage(org.glassfish.admingui.devtests.MonitoringTest)

In this, will change the test.. But still, it doesn't show up the monitoring data for garbage collectors. As there is a space in all the garbage collectors(Ex : PS Scavenge).
Encoded value of "PS Scavenge" is "PS+Scavenge". For both the values, it is not showing the data. It is able to get the data using "PS%20Scavenge". How can we resolve the issue?
The output for Garbage collectors URL is,
> curl -X GET "http://localhost:4848/monitoring/domain/server/jvm/garbage-collectors/PS Scavenge"
No output
>curl -X GET "http://localhost:4848/monitoring/domain/server/jvm/garbage-collectors/PS+Scavenge"
<html><head><title>GlassFish REST Interface</title> <link rel="stylesheet" type="text/css" href="http://localhost:4848/monitoring/static/std.css" /></head> <body><h1 class="mainheader">GlassFish REST Interface</h1><hr/></div></body></html>
>curl -X GET "http://localhost:4848/monitoring/domain/server/jvm/garbage-collectors/PS%20Scavenge"
<html><head><title>GlassFish REST Interface</title> <link rel="stylesheet" type="text/css" href="http://localhost:4848/monitoring/static/std.css" /></head> <body><h1 class="mainheader">GlassFish REST Interface</h1><hr/><ul><li><a href="http://localhost:4848/monitoring/domain/server/jvm/garbage-collectors /PS%20Scavenge/collectioncount-count">collectioncount-count</a><ul><li>count : 66</li><li>lastsampletime : 1294806042121</li><li>description : Total number of collections that have occurred</li><li>unit : count</li><li>name : CollectionCount</li><li>starttime : 1294804774713</li></ul></li><li><a href="http://localhost:4848 /monitoring/domain/server/jvm/garbage-collectors/PS%20Scavenge/collectiontime-count">collectiontime-count</a><ul><li>count : 1009</li><li>lastsampletime : 1294806042121</li><li>description : Approximate accumulated collection elapsed time in milliseconds</li><li>unit : millisecond</li><li>name : CollectionTime</li><li>starttime : 1294804774713</li></ul></li></ul></div></body></html>

Comment by sumasri [ 16/Jan/11 ]

These are the latest results from hudson.

[artifact:mvn] testMonitoringApplicationsPage(org.glassfish.admingui.devtests.MonitoringTest)
//Once the deployWar test in ApplicationTest work, this will get resolved.

[artifact:mvn] testResourceAdapterConfigs(org.glassfish.admingui.devtests.ResourceAdapterConfigsTest)
[artifact:mvn] testMonitoringServerPage(org.glassfish.admingui.devtests.MonitoringTest)
//For these 2 tests, waiting for Jason's comments.

Comment by Anissa Lam [ 18/Jan/11 ]

Since testDeployWar in ApplicationTest is facing the same issue as testMonitoringApplicationPage, and you are looking into this with Jason, please take care of testDeployWar once the solution is found.
thanks.

Comment by sumasri [ 06/Jul/11 ]

All dev tests are passing. Hence, marking it as fixed.





[GLASSFISH-15548] Dev Test Failure(s) Created: 12/Jan/11  Updated: 12/Jan/11  Due: 14/Jan/11  Resolved: 12/Jan/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-15444 Dev test failures Open
Tags: 3_1-review

 Description   

Per Nazrul's email:

Srini (9)

Failed tests:
[artifact:mvn] testAddMessageSecurityConfiguration(org.glassfish.admingui.devtests.SecurityTest)
[artifact:mvn] testJvmProfiler(org.glassfish.admingui.devtests.JvmSettingsTest)
[artifact:mvn] testHttpService(org.glassfish.admingui.devtests.HttpServiceTest)
[artifact:mvn] testAvailabilityService(org.glassfish.admingui.devtests.AvailabilityServiceTest)
[artifact:mvn] testWebContainerAvailability(org.glassfish.admingui.devtests.AvailabilityServiceTest)
[artifact:mvn] testEjbContainerAvailability(org.glassfish.admingui.devtests.AvailabilityServiceTest)

[artifact:mvn] Tests in error:
[artifact:mvn] testSecurityPage(org.glassfish.admingui.devtests.SecurityTest)
[artifact:mvn] testMigrateEjbTimers(org.glassfish.admingui.devtests.ClusterTest)
[artifact:mvn] testProperties(org.glassfish.admingui.devtests.StandaloneTest)



 Comments   
Comment by Nazrul [ 12/Jan/11 ]

Adding 3_1-review to exclude this from un-scrubbed list

Comment by srinik76 [ 12/Jan/11 ]

Fixed all the cases as mentioned in the bug description. The following is the latest failures report from Hudson

Results :
[artifact:mvn]
[artifact:mvn] Failed tests:
[artifact:mvn] testAdminObjectResources(org.glassfish.admingui.devtests.AdminObjectTest)
[artifact:mvn] testAdminObjectResourcesWithTargets(org.glassfish.admingui.devtests.AdminObjectTest)
[artifact:mvn] testDeployWar(org.glassfish.admingui.devtests.ApplicationTest)
[artifact:mvn] testLifecycleModules(org.glassfish.admingui.devtests.LifecycleModulesTest)
[artifact:mvn] testMonitoringApplicationsPage(org.glassfish.admingui.devtests.MonitoringTest)
[artifact:mvn] testCreateAndDeleteNode(org.glassfish.admingui.devtests.NodeTest)
[artifact:mvn] testUpdateNode(org.glassfish.admingui.devtests.NodeTest)
[artifact:mvn] testDeleteWithInstance(org.glassfish.admingui.devtests.NodeTest)
[artifact:mvn] testResourceAdapterConfigs(org.glassfish.admingui.devtests.ResourceAdapterConfigsTest)
[artifact:mvn] testProperties(org.glassfish.admingui.devtests.StandaloneTest)
[artifact:mvn]
[artifact:mvn] Tests in error:
[artifact:mvn] testJdbcResourcesWithTargets(org.glassfish.admingui.devtests.JdbcTest)
[artifact:mvn] testAddingConnectionFactoriesWithTargets(org.glassfish.admingui.devtests.JmsResourcesTest)
[artifact:mvn] testCustomResourcesWithTargets(org.glassfish.admingui.devtests.JndiTest)
[artifact:mvn] testExternalResourcesWithTargets(org.glassfish.admingui.devtests.JndiTest)
[artifact:mvn] testMonitoringServicePage(org.glassfish.admingui.devtests.MonitoringTest)
[artifact:mvn] testMonitoringServerPage(org.glassfish.admingui.devtests.MonitoringTest)

Comment by srinik76 [ 12/Jan/11 ]

Closing the bug as all the failures and errors are addressed as per the latest report from hudson.





[GLASSFISH-15547] Dev Test Failure(s) Created: 12/Jan/11  Updated: 18/Jan/11  Due: 14/Jan/11  Resolved: 18/Jan/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-15444 Dev test failures Open
Tags: 3_1-review

 Description   

Per Nazrul's email:

Failed tests:
[artifact:mvn] testCreateAndDeleteNode(org.glassfish.admingui.devtests.NodeTest)
[artifact:mvn] testUpdateNode(org.glassfish.admingui.devtests.NodeTest)
[artifact:mvn] testDeleteWithInstance(org.glassfish.admingui.devtests.NodeTest)
[artifact:mvn] testDeployWar(org.glassfish.admingui.devtests.ApplicationTest)

[artifact:mvn] Tests in error:
[artifact:mvn] testCreateAndDeleteStandaloneInstance(org.glassfish.admingui.devtests.StandaloneTest)



 Comments   
Comment by Nazrul [ 12/Jan/11 ]

Adding 3_1-review to exclude this from un-scrubbed list

Comment by Anissa Lam [ 13/Jan/11 ]

Standalone Test is fixed. all 3 tests passed.

Looking into ApplicationTest and NodeTest.

Comment by Anissa Lam [ 17/Jan/11 ]

Node test was obsoleted as GUI supports SSH/CONFIG node.
All node test has been updated and is passing.

So, the only test that still needs to be fixed is the ApplicationTest for testing deploy war.

Comment by Anissa Lam [ 18/Jan/11 ]

The only test thats under me that is failing is the testDeployWar in ApplicaionTest.
The deploy page is different than other pages due to the fact that all the fields from different plugin is in a frame of that page.
Suma is facing the same issue for the testMonitoringApplicationsPage page and is looking into this with Jason.
I will add testDeployWar to GLASSFISH-15549 as Suma is working on this and close this bug.





[GLASSFISH-15546] [UB]Built-in-custom-resource : PropertiesFactory : need correction in attribute name "fileName" Created: 12/Jan/11  Updated: 23/Feb/11  Resolved: 23/Feb/11

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

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


 Description   

Please refer the last comment from user "sdoca" in issue
http://java.net/jira/browse/GLASSFISH-15402

The property name to specify a "properties" file name is "org.glassfish.resources.custom.factory.PropertiesFactory.fileName", but it is documented as
"fileName"
Please refer : http://docs.sun.com/app/docs/doc/821-1752/giysn?l=en&a=view

Fix is to change the "fileName" to "org.glassfish.resources.custom.factory.PropertiesFactory.fileName" in docs.

Reference - v3 one-pager :
http://wikis.sun.com/display/GlassFish/GFV3JDBCOnePager

Section : 4.1.7 "PropertiesFactory"

"File-location is specified via the property org.glassfish.resources.custom.factory.PropertiesFactory.fileName"



 Comments   
Comment by Paul Davies [ 12/Jan/11 ]

Affects App Dev Guide. Reassigned to Rebecca Parks.

Comment by Rebecca Parks [ 12/Jan/11 ]

The full name of the property is implied by the full name of the class, which is listed in the first paragraph of the section. But just for absolute clarity, I added the full name of the property at the first mention of it, in the first bulleted item. You will see this fix when I send the App Dev Guide out for review.

Comment by Rebecca Parks [ 23/Feb/11 ]

All the 3.1 docs have been posted for a sign-off review, so presumably this fix can be verified. Resolving.





[GLASSFISH-15540] osgi.bundle exports in GF V3.1 security/jaspic-provider-framework module too restrictive Created: 11/Jan/11  Updated: 13/Jan/11  Due: 18/Jan/11  Resolved: 13/Jan/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Attachments: Java Archive File jaspic.provider.framework.jar    
Tags: 3_1-approved

 Description   

Message from Ron :
-----------
Hi Chris and Nazrul,

the jar that is effected, contains a portable and pluggable jsr 196 configuration utility that makes it easy to configure new
servlet container authentication mechanisms within any jsr 196 compatible Servlet container (via a jass configuration file;
e.g. login.conf in domainx/config). The jar was created to sustain a simple and portable authentication mechanism configuration
model. Unfortunately the restricted exports have the effect of making this utility inaccessible within Glassfish; leaving available
only the proprietary/non-portable configuration utilities that are not applicable to/and comapible with servlet containers other than glassfish.
-----------



 Comments   
Comment by kumarjayanti [ 11/Jan/11 ]

How bad is its impact? (Severity)
Does not impact GFV3.1 as such but prevent GlassFish V3.1 being used to demonstrate some pluggable Authentication Modules based on the new JAAS based configuration system that has been built into the JSR-196 RI.

How often does it happen? (Frequency)
Effects development of pluggable Authentication Modules based on the new JAAS based config system.

How much effort is required to fix it? (Cost)
minor, adding exports to osgi.bundle

What is the risk of fixing it? (Risk)
Would like jerome/sahoo to assess performance impact (if any). We are taking of exporting 3 more packages in the osgi.bundle, resulting in 5 classes to be exported in total.

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?
This feature is not an advertised feature and hence does not require release-noting but as discussed offline, Ron is trying to use this for some important, strategic higher level work and he cannot use V3.0.1 for that since V3.0.1 does not have this new JAAS based config system support in it.

Comment by kumarjayanti [ 11/Jan/11 ]

svn diff of the fix :

Index: osgi.bundle
===================================================================
— osgi.bundle (revision 44351)
+++ osgi.bundle (working copy)
@@ -38,7 +38,10 @@

  1. holder.
    #
    -exportcontents: \
    + com.sun.jaspic.config.delegate; \
    com.sun.jaspic.config.factory; \
    + com.sun.jaspic.config.jaas; \
    + com.sun.jaspic.config.servlet; \
    com.sun.logging.enterprise.system.jaspic.security; \
    com.sun.jaspic.config.helper; version=$ {project.osgi.version}
Comment by kumarjayanti [ 11/Jan/11 ]

assign it to myself

Comment by kumarjayanti [ 12/Jan/11 ]

Amit can you test with this jar to see if there is any perf regression

Comment by Chris Kasso [ 13/Jan/11 ]

Approved for 3.1. The results from the perf runs showed no performance impact.

Comment by kumarjayanti [ 13/Jan/11 ]

fixed





[GLASSFISH-15536] JaxwsFromWsdl test in QL fails with security manager on Created: 11/Jan/11  Updated: 18/Feb/11  Due: 18/Jan/11  Resolved: 17/Jan/11

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

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

Linux


Attachments: Zip Archive grantinfo.log.zip     Text File log.txt     Text File patch.txt     Text File server.log    
Issue Links:
Dependency
depends on GLASSFISH-15556 Privileged code block missing in osgi... Resolved
Tags: 3-1-regression, 3_1-approved, 3_1-regression, 3_1-verified

 Description   

On b37 nightly, tried to run QL under security-manager-on mode and got following exception for quicklook/wsit/JaxwsFromWsdl test:
[#|2011-01-11T16:31:56.648-0800|SEVERE|glassfish3.1|com.sun.xml.ws.servlet.http|_ThreadID=22;_ThreadName=Thread-1;|caught throwable
java.lang.IllegalAccessError: Class com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection can not access a member of class com.sun.xml.ws.fault.SOAP11Fault with modifiers "private"
at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.get(Accessor.java:263)
at com.sun.xml.bind.v2.runtime.reflect.Accessor.getUnadapted(Accessor.java:147)
at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.hasValue(TransducedAccessor.java:251)
at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serializeBody(SingleElementLeafProperty.java:105)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:344)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:597)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:328)
...

The stack trace is attached. Steps to reproduce:
1. Start GF3.1 DAS.
2. cd quicklook; ant -Dglassfish.home=$

{GF_HOME} add-quicklook-policy-grants enable-security-manager
3. ant -Dglassfish.home=${GF_HOME}

stop-server start-server-felix
4. cd wsit/JaxwsFromWsdl; ant -Dglassfish.home=$

{GF_HOME}

all



 Comments   
Comment by Bhakti Mehta [ 11/Jan/11 ]

Requesting Martin's input

Comment by Martin Grebac [ 12/Jan/11 ]

JAXB didn't get enough permissions to run.

Comment by kumarjayanti [ 12/Jan/11 ]

Here is the full stack trace :

[#|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))|#]

[#|2011-01-12T22:12:27.996+0530|INFO|glassfish3.1|javax.enterprise.system.core.security|_ThreadID=20;_ThreadName=Thread-1;|JACC Policy Provider: Failed Permission Check, context(JaxwsFromWsdl/JaxwsFromWsdl)- permission((java.lang.reflect.ReflectPermission suppressAccessChecks))|#]

[#|2011-01-12T22:12:27.999+0530|WARNING|glassfish3.1|com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection|_ThreadID=20;_ThreadName=Thread-1;|Unable to make com.sun.xml.ws.fault.SOAP11Fault.faultcode accessible.
java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
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 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.<init>(Accessor.java:245)
at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.<init>(Accessor.java:232)
at com.sun.xml.bind.AccessorFactoryImpl.createFieldAccessor(AccessorFactoryImpl.java:70)
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl.createFieldSeed(RuntimeClassInfoImpl.java:265)
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl.createFieldSeed(RuntimeClassInfoImpl.java:86)
at com.sun.xml.bind.v2.model.impl.ClassInfoImpl.findFieldProperties(ClassInfoImpl.java:409)
at com.sun.xml.bind.v2.model.impl.ClassInfoImpl.getProperties(ClassInfoImpl.java:312)
at com.sun.xml.bind.v2.model.impl.RuntimeClassInfoImpl.getProperties(RuntimeClassInfoImpl.java:186)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:247)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:104)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:85)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getClassInfo(ModelBuilder.java:213)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:99)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.getClassInfo(RuntimeModelBuilder.java:85)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:319)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.getTypeInfo(ModelBuilder.java:334)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:483)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:319)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1170)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:145)
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.newInstance(ContextFinder.java:228)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:215)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:401)
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)

#]
Comment by kumarjayanti [ 12/Jan/11 ]

First this exception occurs :

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

#]

And this has to be fixed. After that JAXB would have to resolve the second exception.

The class com.sun.xml.bind.v2.runtime.reflect.Accessor from which the exception is emerging, is in GF/modules/jaxb-osgi.jar

and it has been given AllPermissions. Here is the server.policy snippet that gives all permissions to all classes/jars in GF/modules dir :

// Core server classes get all permissions by default
grant codeBase "file:$

{com.sun.aas.installRoot}

/modules/-"

{ permission java.security.AllPermission; }

;

So there is nothing more the security team can do here. It appears that the CallStack leading to the exception has application code somewhere down the line which obviously does not have this permission and hence the exception.

So JAXB will have to execute such code in doPrivileged block.

boolean secMgrEnabled = ...

if (!secMgrEnabled)

{ java.lang.reflect.AccessibleObject.setAccessible(...); }

else {

AccessController.doPrivileged(new PrivilegedAction() {
public Object run()

{ java.lang.reflect.AccessibleObject.setAccessible(...); return null; }

});
}

Comment by kumarjayanti [ 12/Jan/11 ]

reassing to OSGI to begin with. Please reassign to JAXB after fixing the OSGI issue.

Comment by Sanjeeb Sahoo [ 12/Jan/11 ]

Someone (most probably the bug submitter) should tell me why it took so long to discover this bug.

Comment by mzh777 [ 12/Jan/11 ]

The GF nightly build is supposed to run QL in security-manager-on mode. But it's running in regular mode twice. This was found during a recent mail exchange with Jane and other engineers.

Comment by Martin Grebac [ 13/Jan/11 ]

I don't understand how can this become a jaxb issue now and wasn't an issue in any older GF version with the JAXB code untouched?

Comment by kumarjayanti [ 13/Jan/11 ]

Martin,

The main thing to locate is an application-frame in the callstack leading to the failure. Since application objects are not given this permission, if the callstack contains an Application Object which is calling back into the JAXB runtime (via JAXB API's) then even though the JAXB runtime has the permission the overall permission check will fail. IOW all the frames on the callstack need to have that permission for the overall permission check to succeed.

Can you identity any application object in the call stack (Exception stack trace) ?.

As far as permissions to jaxb-osgi.jar and jaxb-api-osgi.jar is concerned we have given ALL permissions to both of them :

A codeBase with a trailing "/-" matches all files (both class and JAR files) in the directory and recursively all files in subdirectories contained in that directory.

And we have the following in server.policy :

// Core server classes get all permissions by default
grant codeBase "file:$

{com.sun.aas.installRoot}

/modules/-"

{ permission java.security.AllPermission; }

;

Comment by kumarjayanti [ 13/Jan/11 ]

The other thing to note is, the Permission failure from JAXB is only a WARNING
#|2011-01-12T22:12:27.999+0530|WARNING|glassfish3.1|com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection|_ThreadID=20;_ThreadName=Thread-1;|Unable to make com.sun.xml.ws.fault.SOAP11Fault.faultcode accessible.

Whereas the Permission failure from OSGI is a SEVERE one

#|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.

so for all you know the testcase may start working after the OSGI fix by sahoo.

Comment by Sanjeeb Sahoo [ 13/Jan/11 ]

Created a separate bug for osgi file

Comment by Sanjeeb Sahoo [ 13/Jan/11 ]

The osgi file will be fixed in GLASSFISH-15556, so reassigning this to WS team.

Comment by Bhakti Mehta [ 13/Jan/11 ]

Reassigning this issue to Martin

Comment by Bhakti Mehta [ 13/Jan/11 ]

Martin, If you feel the issue should be reassinged to the submitter once the bug 15556 is fixed please mark it accornindlgy

Comment by Martin Grebac [ 14/Jan/11 ]

I just reproduced this locally with latest GF code. Kumar, the affected Accessor code is below. Note the comment which is there for a long long time. We didn't touch the code (other than modified the logging or so) for a long long time. Would you please answer asap:

  • why does the code fail for GF3.1 and not for older GF versions?
  • your fix suggestion is exactly against the comment - do you still suggest fixing it the way you proposed?

...
int mod = f.getModifiers();
if (!Modifier.isPublic(mod) || Modifier.isFinal(mod) || !Modifier.isPublic(f.getDeclaringClass().getModifiers())) {
try

{ // attempt to make it accessible, but do so in the security context of the calling application. // don't do this in the doPrivilege block, as that would create a security hole for anyone // to make any field accessible. f.setAccessible(true); }

catch (SecurityException e) {
if ((!accessWarned) && (!supressAccessorWarnings))

{ // this happens when we don't have enough permission. logger.log(Level.WARNING, Messages.UNABLE_TO_ACCESS_NON_PUBLIC_FIELD.format( f.getDeclaringClass().getName(), f.getName()), e); }

accessWarned = true;
}
}
...

Comment by kumarjayanti [ 14/Jan/11 ]

Since the initial bug report indicated as if the real exception and cause of failure is this :

----------
#|2011-01-11T16:31:56.648-0800|SEVERE|glassfish3.1|com.sun.xml.ws.servlet.http|_ThreadID=22;_ThreadName=Thread-1;|caught throwable
java.lang.IllegalAccessError: Class com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection can not access a member of class com.sun.xml.ws.fault.SOAP11Fault with modifiers "private"
-----------

So i had suggested code changes in JAXB.

But when i actually ran the QL test, here is what i saw :

--------
[#|2011-01-12T22:12:27.999+0530|WARNING|glassfish3.1|com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection|_ThreadID=20;_ThreadName=Thread-1;|Unable to make com.sun.xml.ws.fault.SOAP11Fault.faultcode accessible.
java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
--------

Can you see the difference. The first one reported was a SEVERE message and the one i saw was a WARNING.

So i had infact said that you probably do not have to do anything else after sahoo fixes the OSGI problem.

I agree with the comment that it can become a security-hole. Is the testcase now working on latest builds after sahoo's fix ?. I guess it should.

Comment by Martin Grebac [ 14/Jan/11 ]

No, it's still not working after Sahoo's fix.

Comment by kumarjayanti [ 14/Jan/11 ]

what is the exception now ?.

Comment by Martin Grebac [ 14/Jan/11 ]

New log.

Comment by Martin Grebac [ 14/Jan/11 ]

It's still the same, see the log.txt.

Comment by kumarjayanti [ 14/Jan/11 ]

ok i understand:

setAccessible failed first and
---------
[#|2011-01-14T15:44:50.099+0530|WARNING|glassfish3.1|com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection|_ThreadID=19;_ThreadName=Thread-1;|Unable to make com.sun.xml.ws.fault.SOAP11Fault.faultcode accessible.
java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
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 java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
--------

And then JAXB is actually trying to do a get of that private member later on :

----------
[#|2011-01-14T15:44:50.187+0530|SEVERE|glassfish3.1|com.sun.xml.ws.servlet.http|_ThreadID=19;_ThreadName=Thread-1;|caught throwable
java.lang.IllegalAccessError: Class com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection can not access a member of class com.sun.xml.ws.fault.SOAP11Fault with modifiers "private"
at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.get(Accessor.java:263)
at com.sun.xml.bind.v2.runtime.reflect.Accessor.getUnadapted(Accessor.java:147)
--------

So do we know why JAXB needs to access this particular private field ?. And why this was not a problem in 3.0.1

Comment by Martin Grebac [ 14/Jan/11 ]

Hmm, good question. Actually I'm not sure whether the same jaxws quicklook test was run with 3.0.1 as well or whether it's a new test.

Comment by Martin Grebac [ 14/Jan/11 ]

mzh777: is the remaining jaxb issue really a regression? Did the JAXWS quicklook test pass with GF 3.0.1 and security manager on?

Comment by Martin Grebac [ 14/Jan/11 ]

I'm reassigning this back to security for deeper evaluation because

  • I verified the tests are passing with 3.0.1
  • with java.security.debug=access:failure I got the trace below which suggests jaxb-api was not given enough permissions
  • I'm not able to dig more information on my own, especially when setting java.security.debug=all or java.security.debug=access:stack renders GF unable to start - without debugging (and knowledge of) the security code I don't know what is causing the issue
  • feel free to reassign back to me with more info
  • if you know how I could help to provide more information on debugging this issue just let me know

[#|2011-01-14T13:24:46.689+0100|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=98;_ThreadName=Thread-1;|access: domain that failed ProtectionDomain (reference:file:/Users/snajper/work/sources/glassfish/v3-trunk/distributions/glassfish/target/glassfish3/glassfish//modules/endorsed/jaxb-api-osgi.jar <no signer certificates>)
null
<no principals>
java.security.Permissions@e51c7f (
(javax.security.auth.PrivateCredentialPermission javax.resource.spi.security.PasswordCredential * "*" read)
(unresolved javax.security.jacc.WebUserDataPermission / null)
(unresolved com.sun.corba.ee.impl.presentation.rmi.DynamicAccessPermission access null)
(unresolved javax.security.jacc.WebResourcePermission / null)
(unresolved com.sun.enterprise.security.CORBAObjectPermission * *)
(java.util.PropertyPermission apple.laf.* read,write)
(java.util.PropertyPermission java.vm.version read)
(java.util.PropertyPermission java.vendor.url read)
(java.util.PropertyPermission java.vm.name read)
(java.util.PropertyPermission com.apple.macos.useScreenMenuBar read,write)
(java.util.PropertyPermission java.version read)
(java.util.PropertyPermission file.separator read)
(java.util.PropertyPermission java.specification.vendor read)
(java.util.PropertyPermission line.separator read)
(java.util.PropertyPermission java.vm.specification.version read)
(java.util.PropertyPermission java.vm.specification.vendor read)
(java.util.PropertyPermission * read,write)
(java.util.PropertyPermission os.name read)
(java.util.PropertyPermission java.vm.vendor read)
(java.util.PropertyPermission path.separator read)
(java.util.PropertyPermission java.specification.name read)
(java.util.PropertyPermission os.version read)
(java.util.PropertyPermission com.apple.hwaccel read,write)
(java.util.PropertyPermission mrj.version read)
(java.util.PropertyPermission os.arch read)
(java.util.PropertyPermission apple.awt.* read,write)
(java.util.PropertyPermission java.class.version read)
(java.util.PropertyPermission java.vendor read)
(java.util.PropertyPermission java.vm.specification.name read)
(java.util.PropertyPermission java.specification.version read)
(java.io.FilePermission /var/folders/KT/KTu593M1GymvSaqcgVUBQE+++TM/Tmp//- delete)
(java.io.FilePermission /Users/snajper/work/sources/glassfish/v3-trunk/distributions/glassfish/target/glassfish3/glassfish/domains/domain1/lib/databases/- delete)
(java.io.FilePermission <<ALL FILES>> read,write)
(java.net.SocketPermission localhost:1024- listen,resolve)
(java.net.SocketPermission * connect,resolve)
(java.lang.RuntimePermission getClassLoader)
(java.lang.RuntimePermission loadLibrary.*)
(java.lang.RuntimePermission accessDeclaredMembers)
(java.lang.RuntimePermission getProtectionDomain)
(java.lang.RuntimePermission modifyThreadGroup)
(java.lang.RuntimePermission stopThread)
(java.lang.RuntimePermission setContextClassLoader)
(java.lang.RuntimePermission queuePrintJob)
(javax.management.MBeanTrustPermission register)
(javax.management.MBeanPermission [com.sun.messaging.jms.*:*] *)
)

Comment by Martin Grebac [ 14/Jan/11 ]

Finally managed to get more debugging info using a very simple policy file and 'java.security.debug=scl,policy'. See attached grantinfo.log. I used this simple policy definition:

grant codeBase "file:$

{com.sun.aas.installRoot}

/-"

{ permission java.security.AllPermission; };
grant codeBase "http://felix.extensions:9/" { permission java.security.AllPermission; }

;
grant

{[snip]}

;

With this definition, when jaxb-osgi is being checked for granted policies, it matches the first policy:
[#|2011-01-14T20:35:15.779+0100|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=107;_ThreadName=Thread-1;|policy: evaluate codesources:
Policy CodeSource: (file:/Users/snajper/work/sources/glassfish/v3-trunk/distributions/glassfish/target/glassfish3/glassfish/- <no signer certificates>) Active CodeSource: (file:/Users/snajper/work/sources/glassfish/v3-trunk/distributions/glassfish/target/glassfish3/glassfish/modules/jaxb-osgi.jar <no signer certificates>)|#]

[#|2011-01-14T20:35:15.779+0100|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=107;_ThreadName=Thread-1;|policy: evaluate principals: Policy Principals: []
Active Principals: []|#]
[#|2011-01-14T20:35:15.779+0100|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=107;_ThreadName=Thread-1;|policy: granting (java.security.AllPermission <all permiss
ions> <all actions>)|#]
[#|2011-01-14T20:35:15.779+0100|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=107;_ThreadName=Thread-1;|policy: evaluation (codesource/principals) passed|#]

Samilarly it matches for felix.jar, osgi-resource-locator.jar or any other module jar under GF install dir. With one exception, the jaxb-api-osgi.jar. See matching log for jaxb-api-osgi.jar:

[#|2011-01-14T20:35:15.808+0100|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=107;_ThreadName=Thread-1;|policy: evaluate codesources:
Policy CodeSource: (file:/Users/snajper/work/sources/glassfish/v3-trunk/distributions/glassfish/target/glassfish3/glassfish/- <no signer certificates>)
Active CodeSource: (reference:file:/Users/snajper/work/sources/glassfish/v3-trunk/distributions/glassfish/target/glassfish3/glassfish//modules/endorsed/jaxb-api-osgi.jar <no signer certificates>)|#]

[#|2011-01-14T20:35:15.809+0100|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=107;_ThreadName=Thread-1;|policy: evaluation (codesource) failed|#]

Note the match failed for this jar. I assume that's because of the active codesource of the api jar. Its' codesource is 'reference:file:/ instead of only a 'file:/'. It also has two slashes before modules: 'glassfish//modules'. I don't know what makes jaxb-osgi-api.jar different to other jars, but I suspect it's somewhere in the osgi loader.
So maybe this is not a security, but osgi issue.
Note I also tried to hack it around by adding grant for reference:file:/ but that does not work as it's not recognized protocol.

Comment by kumarjayanti [ 14/Jan/11 ]

Martin,

Thanks for spending time and digging up the root cause so well.

Comment by kumarjayanti [ 14/Jan/11 ]

Martin's analysis shows that the codesource URL is being wrongly computed by the classloader for endorsed jars leading to incorrect getPermissions() evaluation for the ProtectionDomain

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

[#|2011-01-15T11:04:32.504+0530|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=101;_ThreadName=Thread-1;|policy: getPermissions:
PD CodeSource: (reference:file:/Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish//modules/endorsed/jaxb-api-osgi.jar <no signer certificates>)
PD ClassLoader: null
PD Principals: <no principals>|#]

[#|2011-01-15T11:04:32.504+0530|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=101;_ThreadName=Thread-1;|policy: evaluate codesources:
Policy CodeSource: (file:/Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/modules/- <no signer certificates>)
Active CodeSource: (reference:file:/Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish//modules/endorsed/jaxb-api-osgi.jar <no signer certificates>)|#]

[#|2011-01-15T11:04:32.505+0530|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=101;_ThreadName=Thread-1;|policy: evaluation (codesource) failed|#]

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

Log shows the evaluation which should have passed, but fails in reality because the Active CodeSource is incorrect. It has two problems :

1. URL starts with unrecognized "reference:" prefix
2. It has two forward-slashes after glassfish (glassfish//modules)

Not sure if (2) is also a problem, but (1) definitely is a problem.

reassigning to OSGI for further investigation.

Comment by Sanjeeb Sahoo [ 16/Jan/11 ]

Kumar and Martin have commented the following about the code source being
reference:file:/Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish//modules/endorsed/jaxb-api-osgi.jar:

1. URL starts with unrecognized "reference:" prefix
2. It has two forward-slashes after glassfish (glassfish//modules)

When glassfish is started by "asadmin start-domain," we do set the endorsed dir like this:

<jvm-options>-Djava.endorsed.dirs=$

{com.sun.aas.installRoot}/modules/endorsed${path.separator}${com.sun.aas.installRoot}

/lib/endorsed</jvm-options>

yet, OSGi framework will load classes from bundle space rather than delegating to boot loader because we don't turn on boot delegation. Earlier, some of the JAXB and JAXWS classes were getting loaded by JRE, but that was fixed when in svn rev #42883 (done as part of issue GLASSFISH-14747). So, it looks to me that we need to update the server.policy with following content:

// Endorsed modules are loaded by Felix/Equinox using a difference url scheme called reference, so
// they are not covered by the grants given above.
grant codeBase "reference:file:$

{com.sun.aas.installRoot}

/modules/-"

{ permission java.security.AllPermission; }

;

To address the double "//" issue, we need to fix the felix config file like this:

glassfish.auto.start=reference:$

{com.sun.aas.installRootURI}modules/endorsed/jaxb-api-osgi.jar \
reference:${com.sun.aas.installRootURI}

modules/endorsed/webservices-api-osgi.jar \
reference:$

{com.sun.aas.installRootURI}modules/endorsed/javax.annotation.jar \
reference:${com.sun.aas.installRootURI}

modules/osgi-main.jar

Comment by kumarjayanti [ 16/Jan/11 ]

I am not 100% sure that the classes are loaded by felix, the bug right now appears to be that the classloader whichever that is, is setting the CodeBase URL incorrectly.

Comment by kumarjayanti [ 17/Jan/11 ]

Sahoo,

Both martin and i tried putting the kind of grant that you suggested, but since the java policy parser does not recognize the reference protocol you will see the following in serve.log :

[#|2011-01-17T14:32:39.332+0530|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=76;_ThreadName=Thread-1;|java.security.policy: error adding Entry:
java.net.MalformedURLException: Unknown protocol: reference|#]

So is there a Felix Policy-Parser that can pre-process this file or something like that, or is there something we can do in the code to give these permissions.

It is frustrating that an error in QL configuration has resulted in this error being detected just before an RC.

Comment by Sanjeeb Sahoo [ 17/Jan/11 ]

Solution:
A patch has been attached. We need to stop using reference scheme for installing endorsed bundles.

How bad is its impact? (Severity): High

  • Impacts product security
  • Is a regression of functionality or performance available in a prior release

How often does it happen? (Frequency): affects WS users

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?: No

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

Comment by Sanjeeb Sahoo [ 17/Jan/11 ]

ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -F msg osgi-platforms/
Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
Transmitting file data ..
Committed revision 44536.





[GLASSFISH-15531] IPS package description update Created: 11/Jan/11  Updated: 18/Jan/11  Due: 18/Jan/11  Resolved: 18/Jan/11

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

Several IPS packages introduced in 3.1 release need updated package description string instead of placeholder.

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

  • An in-your-face issue that will touch the majority of users. Package screen names and descriptions are very visible elements in updatetool client and affect usability.

How often does it happen? (Frequency)
Always.

How much effort is required to fix it? (Cost)
Minimal effort, package description strings need to be updated.

What is the risk of fixing it? (Risk)
Minimal, no code change.

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?
No.



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

Approved for 3.1

Comment by Snjezana Sevo-Zenzerovic [ 18/Jan/11 ]

Package descriptions have been updated in r44566 (packager module) and r44570 (distributions module).





[GLASSFISH-15526] internal wiki page output in security module during upgrade from EE profile Created: 11/Jan/11  Updated: 12/Jan/11  Resolved: 12/Jan/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

This text shouldn't be hard-coded and shouldn't reference an internal wiki (com.sun.enterprise.security.SecurityUpgradeService.java):

SEVERE: AutoUpgrade from v2 EE edition to v3 is not currently supported.Please refer to the instructions in http://wikihome.sfbay.sun.com/security/Wiki.jsp?page=V2.XEEToV3.1NSSUpgrade for upgrading manually

I don't know whether it should contain the public wiki page or say something about referring to the upgrade guide instead. Either way, it probably shouldn't use the term "AutoUpgrade," which may be confusing.

Possibly more of a problem: this message is seen even when the manual steps are followed as well. Since this message can't even be reached unless the manual steps are taken (otherwise master password check will fail), then maybe it can be removed.



 Comments   
Comment by Nazrul [ 11/Jan/11 ]

Please fix the logging message

Comment by kumarjayanti [ 11/Jan/11 ]

How bad is its impact? (Severity)
Blocker since the message output by the command refer to an internal Wiki for instructions.

How often does it happen? (Frequency)
Upgrade from V2.X EE.

How much effort is required to fix it? (Cost)
minor cleanup the message.

What is the risk of fixing it? (Risk)
None.

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

Comment by kumarjayanti [ 12/Jan/11 ]

fixed

Comment by kumarjayanti [ 12/Jan/11 ]

fixed





[GLASSFISH-15507] [UB]DOC: Server restart is required after secure-admin is enabled or disabled Created: 10/Jan/11  Updated: 11/Apr/11  Resolved: 08/Apr/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b37
Fix Version/s: 3.1_ms08

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


 Description   

Server / instance restart is required after secure admin is enabled or disabled. This is not documented.

Document: Admin Guide
Section : Impact of Configuration Changes - Configuration Changes That Require Server Restart

Please add secure-admin configuration changes to the list.

===================

-bash-3.00$ asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 1873 c1 running
in1 localhost 8107 1877 c1 running
Command list-instances executed successfully.

-bash-3.00$ asadmin enable-secure-admin
Command enable-secure-admin executed successfully.

-bash-3.00$ asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 1873 c1 running; requires restart
in1 localhost 8107 1877 c1 running; requires restart
Command list-instances executed successfully.

=====================



 Comments   
Comment by Paul Davies [ 18/Jan/11 ]

Affects unbundled docs

Comment by Tim Quinn [ 18/Jan/11 ]

I've edited the title and description to include the fact that a restart is required after a disable as well as an enable.

Comment by Scott Fordin [ 18/Mar/11 ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Paul Davies [ 08/Apr/11 ]

To verify the fix, see the attachment to GLASSFISH-15635

Comment by Harshad Vilekar [ 11/Apr/11 ]

Verified the updated doc attachment.





[GLASSFISH-15501] NoSuchMethodException: com.sun.grizzly.config.dom.Ssl.getSslInactivityTimeout() Created: 09/Jan/11  Updated: 10/Jan/11  Resolved: 10/Jan/11

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1_b36
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

Whenever GUI user goes to the SSL tab of a protocol, the following endpoint witout payload is called to get the list of attributes, I see NoSuchMethodException: com.sun.grizzly.config.dom.Ssl.getSslInactivityTimeout() logged in server.log

try the following;

http://localhost:4848/management/domain/configs/config/server-config/network-config/protocols/protocol/http-listener-2/ssl

you will see this exception:
[#|2011-01-09T19:31:37.257-0800|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=93;_ThreadName=admin-thread-pool-4848(4);|java.lang.NoSuchMethodException: com.sun.grizzly.config.dom.Ssl.getSslInactivityTimeout()
at java.lang.Class.getMethod(Class.java:1605)
at org.glassfish.admin.rest.ResourceUtil.getMethodMetaData(ResourceUtil.java:328)
at org.glassfish.admin.rest.provider.ProviderUtil.getHtmlRepresentationForAttributes(ProviderUtil.java:249)
at org.glassfish.admin.rest.provider.ActionReportResultHtmlProvider.getContent(ActionReportResultHtmlProvider.java:108)
at org.glassfish.admin.rest.provider.ActionReportResultHtmlProvider.getContent(ActionReportResultHtmlProvider.java:62)
at org.glassfish.admin.rest.provider.BaseProvider.writeTo(BaseProvider.java:110)
at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:306)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1316)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1229)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1219)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:180)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:145)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:182)
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)

#]


 Comments   
Comment by Jason Lee [ 10/Jan/11 ]

How bad is its impact? (Severity)

Moderate. The attribute in question can not be saved.

How often does it happen? Will many users see this problem? (Frequency)

Every time

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

Very little

What is the risk of fixing it and how will the risk be mitigated? (Risk)

Very little

Diff:

Index: src/main/java/org/glassfish/admin/rest/ResourceUtil.java
===================================================================
— src/main/java/org/glassfish/admin/rest/ResourceUtil.java (revision 44352)
+++ src/main/java/org/glassfish/admin/rest/ResourceUtil.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
    @@ -324,23 +324,32 @@
    Set<String> attributeNames = configBeanModel.getAttributeNames();
    for (String attributeName : attributeNames) {
    String methodName = getAttributeMethodName(attributeName);
    + Method method = null;
    try {
  • Method method = configBeanProxy.getMethod(methodName);
  • Attribute attribute = method.getAnnotation(Attribute.class);
  • if (attribute != null) {
  • ParameterMetaData parameterMetaData = getParameterMetaData(attribute);
  • if (method.getAnnotation(Deprecated.class) != null) { - parameterMetaData.putAttribute(Constants.DEPRECATED, "true"); + method = configBeanProxy.getMethod(methodName); + }

    catch (NoSuchMethodException e) {
    + // Method not found, so let's try a brute force method if the method
    + // can't be found via the method above. For example: for
    + // Ssl.getSSLInactivityTimeout(), we calculate getSslInactivityTimeout,
    + // which doesn't match due to case.
    + for (Method m : configBeanProxy.getMethods())

    Unknown macro: {+ if (m.getName().equalsIgnoreCase(methodName)) { + method = m; }+ }

    + }
    + Attribute attribute = method.getAnnotation(Attribute.class);
    + if (attribute != null) {
    + ParameterMetaData parameterMetaData = getParameterMetaData(attribute);
    + if (method.getAnnotation(Deprecated.class) != null)

    { + parameterMetaData.putAttribute(Constants.DEPRECATED, "true"); + }
  • //camelCase the attributeName before passing out
  • attributeName = eleminateHypen(attributeName);
    + //camelCase the attributeName before passing out
    + attributeName = eleminateHypen(attributeName);
  • methodMetaData.putParameterMetaData(attributeName, parameterMetaData);
  • }
  • } catch (NoSuchMethodException e) { - e.printStackTrace(); + methodMetaData.putParameterMetaData(attributeName, parameterMetaData); + }

    }
    } catch (ClassNotFoundException e) {

Review by Ludo.

Comment by Chris Kasso [ 10/Jan/11 ]

Approved for 3.1

Comment by Jason Lee [ 10/Jan/11 ]

Fix committed (r44362)





[GLASSFISH-15488] "Restart Required" status displayed for remote instance when log level changed, even though no restart is needed Created: 07/Jan/11  Updated: 21/Feb/11  Due: 18/Jan/11  Resolved: 29/Jan/11

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

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

OS :Windows 2008Servers
Browser: firefox 3.6


Issue Links:
Duplicate
duplicates GLASSFISH-15541 setting logger level should not repor... Closed
Tags: 3_1-verified

 Description   

Build used: promoted b36.

Installed GF on 2 machines( A and B) , DAS Host is machine A, From the Admn Console on m/c A, created a remote node on machine B, using SSH (provided SSH user and password). The remote node in the machine B was created succesfully.
Created a new instance(std-ins1) on this remote-node and started the instance from the console.
In the remote-instances configuration (std-ins1-config),Logger settings page, changed the Log levels from Info to Warning, and clicked save button.
Now for the remote instance "Restart Required" status was displayed.
If we click " Restart" button , the process restarts the instance, but the instances status does not say "Running", but always displays as "Restart Required".

The same issue can be reproduced in CLI as below:

In bigapp-oblade-3.us.oracle.com (DAS HOST)
C:\SQE\V3.1\glassfish\glassfish\bin>asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
std-ins1 asqe-oblade-20.us.oracle.com 24848 3460 — running
requires restart
clus-local-ins1 localhost 24848 4332 cluster1 running
Command list-instances executed successfully.

C:\SQE\V3.1\glassfish\glassfish\bin>asadmin restart-instance std-ins1
std-ins1 was restarted.
Command restart-instance executed successfully.

C:\SQE\V3.1\glassfish\glassfish\bin>asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
std-ins1 asqe-oblade-20.us.oracle.com 24848 3684 — running
requires restart
clus-local-ins1 localhost 24848 4332 cluster1 running
Command list-instances executed successfully.



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

GUI displays whatever is returned by 'list-instance' command. As you can see that CLI list-instance command also shows 'restart required' after you restart the instance. This is not a GUI bug.

transfer to admin.

Comment by Tom Mueller [ 10/Jan/11 ]

It appears that this is related to the restart-instance behavior when dealing with a remote node. This behavior only happens with a remote node, and only if restart-instance is used. I.e., if stop-instance followed by start-instance is used, then the state is reset correctly. I suspect that a restart-instance isn't actually doing the synchronization step, while stop-instance/start-instance does.

Comment by Tom Mueller [ 10/Jan/11 ]

Byron, can you please look at this since it is related to restart-instance?

Comment by Byron Nevins [ 10/Jan/11 ]

I can see no such thing in the logging services page. There is no way to change logging levels in there.
However when I changed something else – the logfile name – all hell broke loose. 15510 was opened on that.

Comment by Byron Nevins [ 10/Jan/11 ]

==============
Here is how restarting works. There are two cases:

(1) non-verbose
The running instance has no terminal window attached. In this case the dying instance creates an asadmin process just before dying. The fresh new asadmin process starts the instance EXACTLY the same way as it was originally started. Naturally that means that synchronization will run (or not run) as it did when it was originally started.

(2) verbose
The instance simply exits with a special return value. Asadmin is running forever in the terminal window. It sees the special value and runs the original start command again – exactly as it ran in the first place.

=================
Note that I have not tried this with a 2 machine setup. I'll try that next.

Comment by Byron Nevins [ 10/Jan/11 ]

Please do some more tests as I've described, report your findings, and reassign to me.

Comment by Byron Nevins [ 10/Jan/11 ]

My earlier comment seems to have been lost!

Shaline: Please repeat everything EXACTLY the same except this time do NOT use SSH to start the remote instance. Instead start it locally from the remote instance machine itself.

I.e. I think this is a SSH-caused problem.

Comment by Byron Nevins [ 10/Jan/11 ]

Easy to read instructions from Tom:

create-node-ssh
create-instance i1 using that node
asadmin start-instance i1
asadmin set-log-levels --target i1 org.apache.coyote=FINE
asadmin list-instances -l (see restart-required)
asadmin restart-instance i1
asadmin list-instance -l (still see restart-required)

Comment by Byron Nevins [ 10/Jan/11 ]

This bug is all over the map.

Currently the big issue is:

1) change log levels, stop, start --> no problem
2) change log levels, restart --> problem

The instance does NOT need to be remote and SSH is NOT needed. THose are red herrings.

You can easily reproduce the above problem with the simplest possible environment of one DAS and one stand-alone instance.

Comment by shaline [ 10/Jan/11 ]

On promoted build 36, I am seeing this issue with remote instances on SSH nodes only, and local instances are restarting fine through CLI.
I will install the latest nightly on windows and will see if I can reproduce this issue without SSH .

Comment by Tom Mueller [ 10/Jan/11 ]

Note: it is not clear that changing a log level should even be setting the restart-required flag. If you run set-log-levels, and then run list-log-levels, the level is as it is set, without doing a restart. So the problem here might be that the restart-required message is being displayed incorrectly.

The reason that the restart-required message is not cleared after a restart is because the domain.xml file was not updated when the log level was set, so the synchronization that happens during the restart does nothing. However, this doesn't explain why the start/stop does clear the restart-required message.

Comment by shaline [ 10/Jan/11 ]

On the latest nightly dated b37-01-10-2011 using the latest-ogs-windows.exe bundle on windows, and latest-ogz.zip bundle on Solaris Sparc 10, In the AdminConsole,
--Created a CONFIG node on localhost.
--Created a instance on this local config node.
--started the instance
--Changed the LOG levels from INFO to Warning for this instance's config.
--Restart Required status showed up in GUI.
--Clicked the "restart" button for this instance..
--GUI Hangs forever...

Tried to start the instance from CLI as below:
C:\SQE\V3.1\glassfish\glassfish\bin>asadmin start-local-instance --node local-config-node local-instance
CLI801 Instance is already synchronized
Waiting for local-instance to start .................................

and the command fails after a long time....

Comment by shaline [ 10/Jan/11 ]

This issue is seen only when we create a "new" config node locally, and not the existing "localhost-domain1" node.
On the existing "localhost-domain1" node , if we create an instance, change log levels for the instances config , then the restart/start-local-instance works fine for this instance.

Comment by shaline [ 10/Jan/11 ]

Here are some more updates:
The issue on local instances on local config nodes is not consistently reproducable, and the local instances are "restarting fine", after changing Log levels.
Only the first time after the installation of glassfish, I saw the issue with the local instances as well, but can not reproduce consistently, there after in the same installation.

But the issue with the remote instances restart, on SSH nodes exists on latest nightly as well, and is consistently reproducible.

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

Somebody who understands how the "restart required" flag is set and cleared needs to take a look at this.

FYI, I was not able to reproduce this using instances local to the das. In that case the "restart required" flag was always cleared after a restart-instance.

But I could reproduce this with remote instances. Running restart-instance on the remote instance did not clear the "restart required" flag. In that case I was using SSH. I was unable to test without using SSH (using only the local commands) because I couldn't get secure admin working (bug GLASSFISH-15539).

Comment by Tom Mueller [ 12/Jan/11 ]

Point of fact: a restart of an instance is NOT required after changing the log levels for an instance, despite list-instances -l saying that it is.

Test:
1. create and start a remote instance called i1
2. in another window, tail the server.log file for the instance.
3. run list-instances -l, observe that there is no output to the server.log file
4. run:
asadmin set-log-levels --target i1 javax.enterprise.system.tools.admin=FINEST
5. run list-instances -l, observe that there are several log messages output to the server.log file with the FINE setting.
6. run:
asadmin set-log-levels --target i1 javax.enterprise.system.tools.admin=INFO
7. run list-instance -l, observe that there is no output to the server.log file.

This shows that it really is not necessary to restart the instance when a log level is changed.

So the question is, why does the instance report that it needs to be restarted in the first place.

Comment by shaline [ 27/Jan/11 ]

Verified in promoted b39.

Comment by shaline [ 28/Jan/11 ]

On promoted build 39, I noticed that, the issue is fixed for Log level setting of a remote instance and Restart Required does not show up.
But when I add a JVM option to a remote running instance, (on a SSH node), the "Restart Required" status shows up, and does not get reset after restarting instance.
I tried list-instances -l option, I do see in CLI, the instance is restarted, as the PID is different, but the status still says "Restart Required".
I added the below JVM option " -Djava.security.manager" to a remote instance, on a SSH node.
Summary : Restart Required status for a remote instance does not get Reset.

Comment by Tom Mueller [ 29/Jan/11 ]

The previous comment reports a different bug. Please file a separate issue.
Marking the original bug as fixed.

Comment by shaline [ 10/Feb/11 ]

Verified in b42 nightly dated 02-09-11





[GLASSFISH-15484] Integrate EclipseLink 2.2 RC1 Created: 07/Jan/11  Updated: 07/Jan/11  Resolved: 07/Jan/11

Status: Closed
Project: glassfish
Component/s: entity-persistence
Affects Version/s: None
Fix Version/s: 3.1_ms08

Type: Task Priority: Major
Reporter: Mitesh Meswani Assignee: Mitesh Meswani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved

 Description   

We are planning to ship EclipseLink 2.2 with GlassFish 3.1. EclipseLink 2.2-RC1 was released today and needs to be integrated

How bad is its impact? (Severity)
Need to integrate eagerly to catch any potential regression

How often does it happen? Will many users see this problem? (Frequency)
N/A

How much effort is required to fix it? (Cost)
Requires a pom change. The fix is ready

What is the risk of fixing it and how will the risk be mitigated? (Risk)
Potential regression. Will be running SQE tests for JPA before integrating.






[GLASSFISH-15469] JMS Physical Destinations table behaves incorrectly Created: 06/Jan/11  Updated: 06/Jan/11  Resolved: 06/Jan/11

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

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

Tags: 3_1-approved

 Description   

The table behaves differently, offering the user an inconsistent experience.

1) How bad is its impact? (Severity)
Minor. Merely an inconsistency in behavior and user feedback.

2) How often does it happen? (Frequency)
Every time

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

4) What is the risk of fixing it? (Risk)
Very little

Diff:

Index: admingui/jms-plugin/src/main/resources/physdest/physDestTable.jsf
===================================================================
— admingui/jms-plugin/src/main/resources/physdest/physDestTable.jsf (revision 44266)
+++ admingui/jms-plugin/src/main/resources/physdest/physDestTable.jsf (working copy)
@@ -39,16 +39,26 @@
holder.

-->
-<sun:table id="configs" title="$resource

{i18njms.jmsPhysDestinations.tableTitle}">
+<sun:table id="configs" title="$resource{i18njms.jmsPhysDestinations.tableTitle}

"
+ deselectMultipleButton="$boolean

{true}"
+ deselectMultipleButtonOnClick="setTimeout('admingui.table.toggleButtons(\\\\\'#{pageSession.topActionGroup}\\\\\', \\\\\'#{pageSession.tableId}\\\\\');', 0)"
+ selectMultipleButton="$boolean{true}

"
+ selectMultipleButtonOnClick="setTimeout('admingui.table.toggleButtons(\\\\\'#

{pageSession.topActionGroup}\\\\\', \\\\\'#{pageSession.tableId}\\\\\');', 0)" >
+ <!afterCreate
+ getClientId(component="$this{component}" clientId=>$page{tableId});
+ />
<!facet actionsTop>
<sun:panelGroup id="topActionsGroup1">
+ <!afterCreate
+ getClientId(component="$this{component}" clientId=>$page{topActionGroup});
+ />
<sun:button id="newButton" text="$resource{i18n.button.New}" >
<!command
gf.redirect(page="/jms/physdest/jmsPhysicalDestinationNew.jsf?target=#{pageSession.target}&parentPage=#{pageSession.selfPage}");
/>
</sun:button>

- <sun:button id="deleteButton" text="$resource{i18n.button.Delete}" disabled="#{false}" primary="#{false}"
+ <sun:button id="deleteButton" text="$resource{i18n.button.Delete}" disabled="#{true}" primary="#{false}"
onClick="if (getConfirm(this,'$resource{i18n.msg.JS.confirmDeletePhysicalDestinations}') ) {submitAndDisable(this, '$resource{i18n.button.Processing}');}; return false;" >
<!command
getUIComponent(clientId="$pageSession{configsTableRowGroupId}", component=>$attribute{tableRowGroup});
@@ -65,7 +75,7 @@
gf.redirect(page="#{pageSession.selfPage}");
/>
</sun:button>
- <sun:button id="flushButton" text="$resource{i18njms.jmsPhysDestinations.purge}" primary="#{false}"
+ <sun:button id="flushButton" text="$resource{i18njms.jmsPhysDestinations.purge}" disabled="#{true}" primary="#{false}"
onClick="return submitAndDisable(this, '$resource{i18n.button.Processing}');" >
<!command
getUIComponent(clientId="$pageSession{configsTableRowGroupId}", component=>$attribute{tableRowGroup});
@@ -86,7 +96,7 @@
</facet>

<sun:tableRowGroup id="rowGroup1" selected="#{td.value.selected}" data={"$pageSession{destList}", "$pageSession{tableList2}"} sourceVar="td">
- <ui:event type="beforeCreate">
+ <!beforeCreate
// Add extra table properties...
createList(size="0", result="#{pageSession.tableList2}");
foreach(var="row" list="#{pageSession.destList}") {
@@ -96,14 +106,19 @@
map="#{requestScope.tlMap}");
listAdd(list="#{pageSession.tableList2}", value="#{requestScope.tlMap}");
}
- </ui:event>
+ />
<!afterCreate
getClientId(component="$this{component}" clientId=>$page{configsTableRowGroupId});
/>
- <sun:tableColumn id="col0" selectId="select" rowHeader="$boolean{false}" id="col0">
- <sun:checkbox id="select" selected="#{td.value.selected}" selectedValue="$boolean{true}" />
- </sun:tableColumn>

+ <sun:tableColumn selectId="select" rowHeader="$boolean{false}" id="col0">
+ <sun:checkbox id="select"
+ selected="#{td.value.selected}"
+ selectedValue="$boolean{true}"
+ onClick="setTimeout('admingui.table.toggleButtons(\\\\\'#{pageSession.topActionGroup}

\\\\\', \\\\\'#

{pageSession.tableId}\\\\\'); admingui.table.initAllRows(\\\\\'#{pageSession.tableId}

\\\\\');', 0);"
+ />
+ </sun:tableColumn>
+
// TODO: Fix these links. Combine all of the phys dest pages into one
<sun:tableColumn id="col1" headerText="$resource

{i18n.common.PropertyName}

" sort="name" rowHeader="$boolean

{true}

">
<sun:hyperlink id="nameCol" text="#

{td.value.name}

"



 Comments   
Comment by Jason Lee [ 06/Jan/11 ]

Fix committed (r44281)





[GLASSFISH-15465] weld-guess sample doesn't run due to copyright headers in XHTML Created: 06/Jan/11  Updated: 07/Jan/11  Resolved: 07/Jan/11

Status: Resolved
Project: glassfish
Component/s: sample_apps
Affects Version/s: 3.1_b35
Fix Version/s: 3.1_ms08

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

Windows XP
Java EE SDK 6u2 b35


Tags: 3_1-approved

 Description   

The weld-guess sample uses Facelets pages as the user interface, but the copyright headers inserted into the XHTML cause parsing exceptions at runtime:
WARNING: StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
javax.faces.view.facelets.FaceletException: Error Parsing /home.xhtml: Error Traced[line: 3] Element type "html" must be followed by either attribute specifications, ">" or "/>".

From home.xhtml:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
<!--

DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
...
-->

xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">

Is the copyright header automatically inserted? index.xhtml has the copyright header inserted in the DOCTYPE declaration. Regardless, it breaks the sample.

It's very possible other samples that use XHTML files are incorrect if the copyright header is automatically inserted.



 Comments   
Comment by scatari [ 06/Jan/11 ]

Yes, this invalid insertion of copyright text happened as part of batch update of COPYRIGHT. I did scan through a few other xhtml files and they look ok in the first pass. Will scan through the rest of the files and update with the list if anything else shows up with incorrect copyright.

Comment by scatari [ 06/Jan/11 ]

A few more files that need update

web/jsf/scrumtoys/web/allInOne.xhtml
web/jsf/scrumtoys/web/burndown.xhtml
web/jsf/scrumtoys/web/changeSkin.xhtml
web/jsf/scrumtoys/web/dashboard.xhtml
web/jsf/scrumtoys/web/menu.xhtml
web/jsf/scrumtoys/web/resources/components/title.xhtml
web/jsf/scrumtoys/web/storiesList.xhtml
webbeans/webbeans-guess/web/home.xhtml
webbeans/webbeans-guess/web/template.xhtml

Will also fix issue 15464 as part of this integration if this fix is approved.
Running a few more verification tests before sending this bug for approval.

Comment by scatari [ 06/Jan/11 ]

1. How bad is its impact? (Severity)
Users will not be able to run "scrum toys" JSF sample.

2. How often does it happen? (Frequency)
Everytime GlassFish SDK is installed successfully through the installer.

3. How much effort is required to fix it? (Cost)
2 days as a new version of Sample binaries with the fix have to be hosted and integrated into 3.1 workspace.

4. What is the risk of fixing it? (Risk)
Less risky as the fix is local to specific files under this jsf sample.

Comment by Chris Kasso [ 06/Jan/11 ]

Approved for 3.1

Comment by scatari [ 07/Jan/11 ]

Integrated a new drop of Samples(1.0.04) that includes the fixes for 15464 and 15465.

Fix Reviewed by : Snjezana
Fix Approved by : Chris





[GLASSFISH-15464] Sample app's build scripts has incorrect default location of GlassFish Created: 06/Jan/11  Updated: 07/Jan/11  Resolved: 07/Jan/11

Status: Resolved
Project: glassfish
Component/s: sample_apps
Affects Version/s: 3.1_b35
Fix Version/s: 3.1_ms08

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

Windows XP
Java EE SDK 6u2 b35


Tags: 3_1-approved

 Description   

The build.properties file for the samples:
glassfish3/glassfish/samples/bp-project/build.properties

by default defines the javaee.home as follows:

  1. path to your application server installation
    javaee.home=C:/glassfishv3/glassfish

This is incorrect. To match the default Windows location in the installer it should be:

  1. path to your application server installation
    javaee.home=C:/glassfish3/glassfish


 Comments   
Comment by scatari [ 06/Jan/11 ]

This is not a stopper for 3.1 release. Users anyway have to check and update the javaee.home value to suite their installation directory. Targeting for 3.2.

Comment by Ian Evans [ 06/Jan/11 ]

Given that the samples are installed as an IPS package, there is no reason for the user to manually set javaee.home, since we already know where the samples are relative to GlassFish.

javaee.home=$

{ant.file.main}

/../../../glassfish

Comment by Ian Evans [ 06/Jan/11 ]

I should also note that the one character difference between glassfishv3 and glassfish3 took me a few minutes to figure out why the build scripts were failing. I imagine I'm not the only one, so get ready for user feedback....

Comment by scatari [ 06/Jan/11 ]

If another integration is required for samples(pending 15465 approval) this issue will also be fixed in that integration. Will fix the default location to "c:/glassfish3/glassfish".

Comment by scatari [ 06/Jan/11 ]

1. How bad is its impact? (Severity)
Low to medium impact, but as the samples are changing as part of 15464, this one line fix can be included in the new drop.

2. How often does it happen? (Frequency)
Everytime GlassFish SDK is installed successfully through the installer.

3. How much effort is required to fix it? (Cost)
2 days as a new version of Sample binaries with the fix have to be hosted and integrated into 3.1 workspace.

4. What is the risk of fixing it? (Risk)
Less risky as the fix is local to this specific file.

Comment by Chris Kasso [ 06/Jan/11 ]

Approved for 3.1

Comment by scatari [ 07/Jan/11 ]

Integrated a new drop of Samples(1.0.04) that includes the fixes for 15464 and 15465.

Fix Reviewed by : Snjezana
Fix Approved by : Chris





[GLASSFISH-15436] NPE during _CoordinatorStub.register_synchronization call when SecurityManager is ON Created: 04/Jan/11  Updated: 06/Jan/11  Resolved: 06/Jan/11

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_ms08

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved

 Description   

tx_propagation test fails with SecurityManager ON, and when the actual exception is propagated up the stack, the cause of the failure is: java.lang.NullPointerException
at com.sun.corba.ee.impl.transport.CorbaOutboundConnectionCacheImpl.get(CorbaOutboundConnectionCacheImpl.java)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:215)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:198)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:431)
at org.omg.CosTransactions._CoordinatorStub.register_synchronization(_CoordinatorStub.java:235)
at com.sun.jts.CosTransactions.TopCoordinator.register_synchronization(TopCoordinator.java:2435)

To reproduce:

% cd ejb30/persistence/tx_propagation
% asadmin start-domain
% asadmin create-jvm-options -Djava.security.manager
% asadmin stop-domain
% asadmin start-domain
% asadmin start-database
% ant all



 Comments   
Comment by Ken Cavanaugh [ 04/Jan/11 ]

Marina has verified that the ORB b021 change fixes this problem, so I'll
close this issue once I integrate an ORB that contains the b021 changes.

As a side note, this does seem to indicate that there is an issue in the ORB
tracing facility related to the security manager, as we have seen a similar
failure in another issue (14704 I think). This requires further investigation for
the GF 3.2 release.

Comment by marina vatkina [ 04/Jan/11 ]

This is review request to add initCause() to the exception that otherwise hides the actual error

How bad is its impact? (Severity)
It's not bad, but very unfriendly (and comes from a very old code prior to initCause() availability)

How often does it happen? Will many users see this problem? (Frequency)
When the error happens

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

What is the risk of fixing it and how will the risk be mitigated? (Risk)
Very low - adding initCause() shouldn't cause any risks

Comment by marina vatkina [ 05/Jan/11 ]

With rev 44254 most bleeding cases of suppressing the actual exception are fixed by either attaching it to the new exception via initCause() or by logging. Reviewed by Ken.

Comment by Ken Cavanaugh [ 06/Jan/11 ]

NPE in ORB should be fixed in GF rev 44286.





[GLASSFISH-15434] Remove obsolete commons-codec and sysnet-registration dependencies from the distribution Created: 04/Jan/11  Updated: 05/Jan/11  Resolved: 05/Jan/11

Status: Closed
Project: glassfish
Component/s: packaging
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

GlassFish 3.1 registration implementation has been refactored and as the result it does not depend on external sysnet-registration and commons-codec jars anymore. These jars should be removed from glassfish-registration package and GlassFish distributions.

How bad is its impact? (Severity)
Moderate. We would be shipping unnecessary 3rd party dependencies and commons-codec jar has also been known to interfere with applications attempting to use different commons-codec version - see issue http://java.net/jira/browse/GLASSFISH-15007

How often does it happen? Will many users see this problem? (Frequency)
Issue affects all GlassFish 3.1 installation.

How much effort is required to fix it? (Cost)
Little effort. Module dependency references need to be removed from top level, packager and installer pom files and install wrapper classpath.No actual code change is required at this point.

What is the risk of fixing it and how will the risk be mitigated? (Risk)
Minimal risk. Distribution runtime has already been tested without the presence of these jars and there are no regressions. Installer runtime will also be checked for regressions prior to checkin.



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

Approved for 3.1

Comment by Snjezana Sevo-Zenzerovic [ 05/Jan/11 ]

Revision 44252 contains the fix.





[GLASSFISH-15430] Invalid Resource jdbc/resname__pm Created: 04/Jan/11  Updated: 10/Jan/11  Resolved: 10/Jan/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1_b35
Fix Version/s: 3.1_ms08

Type: Bug Priority: Major
Reporter: aloleary Assignee: Mitesh Meswani
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All



 Description   

Am using Embedded version of Glassfish to bootstrap application.

Command to create the resource succeeds without any failures. However when the application tries to use the resource it outputs the following:

SEVERE: Exception while preparing the app : Invalid resource : jdbc/customname__pm
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Invalid resource : jdbc/customname__pm
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl$MyDataSource.validateResource(ConnectorResourceAdminServiceImpl.java:272)
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl$MyDataSource.setResourceInfo(ConnectorResourceAdminServiceImpl.java:253)
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.lookupDataSourceInDAS(ConnectorResourceAdminServiceImpl.java:243)
at com.sun.enterprise.connectors.ConnectorRuntime.lookupDataSourceInDAS(ConnectorRuntime.java:536)
at com.sun.enterprise.connectors.ConnectorRuntime.lookupPMResource(ConnectorRuntime.java:467)
at org.glassfish.persistence.common.PersistenceHelper.lookupPMResource(PersistenceHelper.java:63)
at org.glassfish.persistence.jpa.ProviderContainerContractInfoBase.lookupDataSource(ProviderContainerContractInfoBase.java:71)
at org.glassfish.persistence.jpa.PersistenceUnitInfoImpl.<init>(PersistenceUnitInfoImpl.java:108)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:154)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:119)
at org.glassfish.persistence.jpa.JPADeployer$1.visitPUD(JPADeployer.java:202)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:475)
at org.glassfish.persistence.jpa.JPADeployer.createEMFs(JPADeployer.java:209)
at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:162)

Note: A similar bug has been marked as resolved http://java.net/jira/browse/GLASSFISH-13672 However I do not have any glassfish-resources.xml which could be used to resolve the issue. It was mentioned in this bug report that the user also found the bug without this file but no extra comments were made on how to resolve.



 Comments   
Comment by Mitesh Meswani [ 04/Jan/11 ]

>Command to create the resource succeeds without any failures.
How are you creating the resource?
To isolate issue, can you please try to lookup resource "jdbc/customname" from your app to see if it succeeds.

Comment by kumm [ 09/Jan/11 ]

I've encountered this exception too.
I've tried to create a jdbc resource form a domain.xml by the maven plugins's 'configFile' property.
But i've found, this setting has ignored.
Filed the issue here: http://java.net/jira/browse/EMBEDDED_GLASSFISH-121

Comment by Mitesh Meswani [ 10/Jan/11 ]

I see that EMBEDDED_GLASSFISH-121 is resolved. I assume it was the root cause of your issue. I am marking this issue as resolved. If you still see the issue, please reopen posting the code you use to create the resource





[GLASSFISH-15422] [STRESS] java.lang.StackOverflowError was thrown against b36 during longevity test in the metro area Created: 03/Jan/11  Updated: 11/Jan/11  Resolved: 11/Jan/11

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: future release
Fix Version/s: 3.1_ms08

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

solaris jdk 6u22


Attachments: Java Archive File gmbal.jar    
Tags: 3_1-blocking

 Description   

Running longevity test with specjent10 against b36 threw the following exception.

http://aras2.us.oracle.com:8080/logs/alacrity.logs_dec_30_solaris_single_run2/results.specjent2010/results_1/driver-results/37/logs/jed-asqe-29/server.log_2010-12-30T19-52-00
[#|2010-12-30T19:41:34.283-0800|WARNING|oracle-glassfish3.1|com.sun.xml.ws.monitoring|ThreadID=10;_ThreadName=Thread-1;|Error while creating monitoring root with name: /_wstx-services-RegistrationService_V11-RegistrationRequesterPort
java.lang.StackOverflowError
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1907)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1907)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
at java.lang.Class.getDeclaredFields(Class.java:1743)
at org.glassfish.gmbal.typelib.TypeEvaluator.getDeclaredFields(TypeEvaluator.java:243)
at org.glassfish.gmbal.typelib.TypeEvaluator.access$600(TypeEvaluator.java:81)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:718)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitParameterizedType(TypeEvaluator.java:502)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:418)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitParameterizedType(TypeEvaluator.java:502)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:418)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitParameterizedType(TypeEvaluator.java:502)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:418)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitParameterizedType(TypeEvaluator.java:502)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:418)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:711)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:709)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:707)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:711)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:709)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:707)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitWildcardType(TypeEvaluator.java:624)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:427)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getBindings(TypeEvaluator.java:787)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitParameterizedType(TypeEvaluator.java:499)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:418)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitParameterizedType(TypeEvaluator.java:502)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:418)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:570)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:558)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$1.evaluate(TypeEvaluator.java:556)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitMethodDeclaration(TypeEvaluator.java:554)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.access$900(TypeEvaluator.java:394)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:733)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$4.evaluate(TypeEvaluator.java:729)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:727)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:711)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor$2.evaluate(TypeEvaluator.java:709)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:95)
at org.glassfish.gmbal.generic.Algorithms.map(Algorithms.java:118)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.processClass(TypeEvaluator.java:707)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.getCorrectDeclaration(TypeEvaluator.java:685)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.visitClassDeclaration(TypeEvaluator.java:467)
at org.glassfish.gmbal.typelib.TypeEvaluator$TypeEvaluationVisitor.evaluateType(TypeEvaluator.java:415)
at org.glassfish.gmbal.typelib.TypeEvaluator.getEvaluatedType(TypeEvaluator.java:318)
at org.glassfish.gmbal.impl.ManagedObjectManagerImpl.constructMBean(ManagedObjectManagerImpl.java:659)
at org.glassfish.gmbal.impl.MBeanTree.setRoot(MBeanTree.java:98)
at org.glassfish.gmbal.impl.ManagedObjectManagerImpl.createRoot(ManagedObjectManagerImpl.java:451)
at com.sun.xml.ws.server.RewritingMOM.createRoot(MonitorBase.java:406)
at com.sun.xml.ws.server.MonitorBase.createRoot(MonitorBase.java:283)
at com.sun.xml.ws.server.MonitorBase.createMOMLoop(MonitorBase.java:214)
at com.sun.xml.ws.server.MonitorBase.createManagedObjectManager(MonitorBase.java:140)
at com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:147)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:236)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:513)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:568)
at org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:260)
at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:99)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4683)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:531)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5303)
at com.sun.enterprise.web.WebModule.start(WebModule.java:497)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:755)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1982)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1630)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:286)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.webservices.metroglue.MetroContainer.deployWsTxServices(MetroContainer.java:221)
at org.glassfish.webservices.metroglue.MetroContainer.deployWsTxServices(MetroContainer.java:170)
at org.glassfish.webservices.metroglue.MetroContainer.onDeployed(MetroContainer.java:157)
at org.glassfish.webservices.WebServiceDeploymentNotifierImpl.notifyDeployed(WebServiceDeploymentNotifierImpl.java:66)
at org.glassfish.webservices.deployment.WebServicesDeploymentMBean.deploy(WebServicesDeploymentMBean.java:302)
at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:188)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:870)
at org.glassfish.javaee.full.deployment.EarDeployer.prepareBundle(EarDeployer.java:290)
at org.glassfish.javaee.full.deployment.EarDeployer.access$200(EarDeployer.java:86)
at org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:141)
at org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:138)
at org.glassfish.javaee.full.deployment.EarDeployer.doOnBundles(EarDeployer.java:215)
at org.glassfish.javaee.full.deployment.EarDeployer.doOnAllTypedBundles(EarDeployer.java:224)
at org.glassfish.javaee.full.deployment.EarDeployer.doOnAllBundles(EarDeployer.java:250)
at org.glassfish.javaee.full.deployment.EarDeployer.prepare(EarDeployer.java:138)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:870)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:410)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:351)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:202)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:128)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:88)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:79)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:64)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:136)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:73)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:243)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
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.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]

All logs:
http://aras2.us.oracle.com:8080/logs/alacrity.logs_dec_30_solaris_single_run2/results.specjent2010/results_1/driver-results/37/logs/jed-asqe-29/
Physical location: /net/asqe-logs.us.oracle.com/export1/gms/alacrity.logs_dec_30_solaris_single_run2/results.specjent2010/results_1/driver-results/37/logs/jed-asqe-29/



 Comments   
Comment by Byron Nevins [ 03/Jan/11 ]

That's a very intense stack trace!

Comment by Byron Nevins [ 04/Jan/11 ]

what ear is being loaded? What happens when you run the same thing with monitoring turned off? How about domain.xml – attach?

The stacktrace can't appear out of nowhere. What commands did you run?

I've never seen anything like this in my environment - so I need instructions on how to reproduce it.

Comment by Byron Nevins [ 04/Jan/11 ]

This looks to be the culprit:

WSEndpoint wsep = WSEndpoint.create(
serviceEndpointClass, // The endpoint class
false, // we do not want JAXWS to process @HandlerChain
inv,
endpoint.getServiceName(), // the service QName
endpoint.getWsdlPort(), // the port
container, // Our container with info on security/monitoring pipe
binding, // Derive binding
primaryWsdl, // primary WSDL
docs, // Collection of imported WSDLs and schema
catalogURL
);

==========================

Comment by Byron Nevins [ 04/Jan/11 ]

Tom -

I don't know whom should get this. It has nothing to do with Monitoring as far as I can see.

It looks like the culprit is either of these in the order I predict/guess:

Web Service (Rajiv?)
GMBAL (Ken)

Comment by Nazrul [ 05/Jan/11 ]

Update from Amit:

As per logs Stackoverflow exception happens just once, and before appserver could start completely. This does not seem to be related to specj. I see org.glassfish.gmbal.impl.* calls going into loop thats results into stackoverflow.

One way to resolve this overflow error is to change -Xss128k to -Xss198k or someone responsible for org.glassfish.gmbal.impl.* needs to see why call sequence is so long.
Perhaps this happens only in sparc setup.

Comment by zorro [ 05/Jan/11 ]

Using the latest specj.ear file to see if StackOverFlow bug gets resolved with this new ear.

Comment by zorro [ 05/Jan/11 ]

Nazrul,

Used the new specj.ear obtained from:
1028851 Dec 30 14:02 /net/hs-usca-07.sfbay.sun.com/export/home3/06/sdo/specj.ear
Ran a sanity run on Solaris against nightly ogs-3.1-b36-12_30_2010.
Results:

1) specj reports:
failed 3
passed 36
/net/asqe-logs/export1/gms/alacrity.logs_01_05_2011/results.specjent2010/results_1/driver-results/44/summary.xml

2)
StackOverFlow is seen in the server log:
/net/asqe-logs/export1/gms/alacrity.logs_01_05_2011/results.specjent2010/results_1/driver-results/44/logs/jed-asqe-29/server.log_2011-01-05T11-07-40

[#|2011-01-05T10:58:28.735-0800|WARNING|oracle-glassfish3.1|com.sun.xml.ws.monitoring|_ThreadID=10;_ThreadName=Thread-1;|Error while creating monitoring root
with name: /__wstx-services-RegistrationService_V11-RegistrationPort
java.lang.StackOverflowError
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1907)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
...

ALL THE LOGS AND CONFIGURATIONS ARE LOCATED AT:
http://aras2.us.oracle.com:8080/logs/alacrity.logs_01_05_2011/results.specjent2010/results_1/driver-results/44/logs/jed-asqe-29/

Physical location:
/net/asqe-logs/export1/gms/alacrity.logs_01_05_2011/results.specjent2010/results_1/driver-results/44/logs/jed-asqe-29

Comment by Nazrul [ 05/Jan/11 ]

Getting help from Ken based on inputs from Amit.

Quality team (zorro) has the SPECj setup that can be used to re-produce this. This is a single instance setup. The problem shows up more frequently in SPARC and blocking stress testing.

Comment by zorro [ 05/Jan/11 ]

Nazrul,

Using build Jan 4 11:16 /net/koori/onestop/glassfish/3.1/promoted/b36/archive/bundles/ogs-3.1-b36.zip and the new specj.ear specj harness reports:

passed 35
failed 4
log location:
/net/asqe-logs/export1/gms/alacrity.logs_01_05_2011_run2/results.specjent2010/results_1/driver-results/45/summary.xml

bugs:
1)
StackOverFlow Exception is seen in:
/net/asqe-logs/export1/gms/alacrity.logs_01_05_2011_run2/results.specjent2010/results_1/driver-results/45/logs/jed-asqe-29/server.log_2011-01-05T12-25-08
[#|2011-01-05T12:15:57.041-0800|WARNING|oracle-glassfish3.1|com.sun.xml.ws.monitoring|_ThreadID=10;_ThreadName=Thread-1;|Error while creating monitoring root
with name: /__wstx-services-Coordinator-RegistrationRequester
java.lang.StackOverflowError
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1907)
...
2)
Also, NPE is seen from specj in:
/net/asqe-logs/export1/gms/alacrity.logs_01_05_2011_run2/results.specjent2010/results_1/driver-results/45/logs/jed-asqe-29/server.log
[#|2011-01-05T12:50:14.641-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=245;_ThreadName=Thread-1;|java.lang.NullPointerException
at org.spec.jent.supplier.emulator.DeliveryHandler.getRandomInRange(DeliveryHandler.java:281)
at org.spec.jent.supplier.emulator.DeliveryHandler.deliverInline(DeliveryHandler.java:198)
at org.spec.jent.supplier.emulator.DeliveryHandler.deliver(DeliveryHandler.java:183)
at org.spec.jent.supplier.emulator.DeliveryHandler.run(DeliveryHandler.java:133)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

#]

All logs and configurations:
/net/asqe-logs/export1/gms/alacrity.logs_01_05_2011_run2/results.specjent2010/results_1/driver-results/45/logs/jed-asqe-29/
http://aras2.us.oracle.com:8080/logs/alacrity.logs_01_05_2011_run2/results.specjent2010/results_1/driver-results/45/logs/jed-asqe-29/

Comment by Alex Pineda [ 06/Jan/11 ]

Amit,

Can you gives us instructions how to modify -Xss128k to -Xss198k so we can try what you suggested.

Comment by Ken Cavanaugh [ 06/Jan/11 ]

I'm assuming for now that this needs to be investigated further for GF 3.1.

Comment by Ken Cavanaugh [ 09/Jan/11 ]

I have created a version of gmbal (still version 3.1.0-b001) that will hopefully provide
better information about the StackOverflowError. Please copy the attached gmbal.jar to the modules
directory of the glassfish installation before running the test.
When the error occurs, you should see a string like the following

SEVERE: GMBALTLIB6: Error thrown from getEvaluatedType for class

{0}

CONTEXT:
(many lines follow starting with ( n) for the number of lines of context associated with the log report)
(a table dump should follow the context)

Please capture all of this information and make it available to me (another attachment to this bug should
be fine for this).

Comment by Ken Cavanaugh [ 09/Jan/11 ]

Please note that this version of gmbal.jar is not yet integrated into the GlassFish 3.1 build,
so you will need to use the attached version on any forthcoming version of GF.
I'll integrate this change as needed once we determine the real problem and it's solution.

Comment by zorro [ 10/Jan/11 ]

used the attached gmbal.jar in this email.
Ran specj against b37 nightly on solaris.

Results:
Caused by: java.lang.StackOverflowError
at java.lang.ClassLoader.defineClass1(Native Method)
...
java.lang.IllegalStateException: SEVERE: "GMBALTLIB6: Error thrown from getEvaluatedType for class class com.sun.xml.ws.server.MonitorRootService"
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
...
All The server.log files and domain.xml files are located at:
http://aras2.us.oracle.com:8080/logs/alacrity.logs_01_10_2011_solaris_gmbal_PATCH_run1/results.specjent2010/results_1/driver-results/49/logs/jed-asqe-29/

specj result summary shows:
passed 35
failed 4
/net/asqe-logs/export1/gms/alacrity.logs_01_10_2011_solaris_gmbal_PATCH_run1/results.specjent2010/results_1/driver-results/49/summary.xml

Comment by amitagarwal [ 11/Jan/11 ]

I apologize for the delay in reply as I was not in this thread.

Instructions to modify -Xss: Search for -Xss setting in specj property file against "j2se.options" or "globalvmoptions" property (whichever is present in your copy of the file) and change it to 198k or 256k. Generally this property is in the beginning of the file.

Comment by zorro [ 11/Jan/11 ]

I ran specj two times with -Xss256k set in the properties file

Result: NO occurrence of StackOverflowError is seen.
I analyzed the logs, except specj's business logic exceptions did not see glassfish related errors.

Please evaluate.

Run 1)
http://aras2.us.oracle.com:8080/logs/alacrity.logs_01_11_2011_solaris_xss256_run1/results.specjent2010/results_1/driver-results/51/logs/jed-asqe-29/

Run 2)
http://aras2.us.oracle.com:8080/logs/alacrity.logs_01_11_2011_solaris_xss256_run2/results.specjent2010/results_1/driver-results/52/logs/jed-asqe-29/

Specj result summary:
Run 1)
passed 36
failed 3
/net/asqe-logs/export1/gms/alacrity.logs_01_11_2011_solaris_xss256_run1/results.specjent2010/results_1/driver-results/51/summary.xml

Run 2)
passed 30
failed 9
/net/asqe-logs/export1/gms/alacrity.logs_01_11_2011_solaris_xss256_run2/results.specjent2010/results_1/driver-results/52/summary.xml

Comment by zorro [ 11/Jan/11 ]

The issue is resolved by setting Xss to 256K.





[GLASSFISH-15417] "Port 2,048" formatting should be "port 2048" in validate-multicast command Created: 03/Jan/11  Updated: 21/Feb/11  Resolved: 21/Feb/11

Status: Resolved
Project: glassfish
Component/s: group_management_service
Affects Version/s: None
Fix Version/s: 3.1_ms08

Type: Bug Priority: Trivial
Reporter: jclingan Assignee: Joe Fialli
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Port number shouldn't have a comma; it is inconsistent formatting when compared to unix CLIs (netstat being a good example). validate-multicast command output shows a port number with a comma:

$ asadmin validate-multicast
Will use port 2,048
Will use address 228.9.3.1
Will use bind interface null
Will use wait period 2,000 (in milliseconds)



 Comments   
Comment by Bobby Bissett [ 04/Jan/11 ]

Once this is integrated, I need to change the admin dev test to test this output more specifically. Right now, the only reason the test passes is because the params in the asadmin command are part of the output from the asadminWithOutput() method. Oops. Am adding this here and am watching the issue so I don't forget.





[GLASSFISH-15408] [UB]remove "Signed Applications" section of upgrade guide Created: 03/Jan/11  Updated: 15/Feb/11  Resolved: 15/Feb/11

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

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-upgrade

 Description   

The "Signed Applications" section of the upgrade guide can be removed. This is the section:

http://docs.sun.com/app/docs/doc/820-7698/gjksr?l=en&a=view

Bugster issue 6851521 was fixed so that redeployment of signed applications is no longer necessary.



 Comments   
Comment by Paul Davies [ 03/Jan/11 ]

Affects Upgrade Guide - prefixed the Summary with [UB] and reassigned to sfordin.

Comment by Scott Fordin [ 15/Feb/11 ]

Removed section.





[GLASSFISH-15396] [Regression] Error reported creating / saving JMS Physical Destination Created: 30/Dec/10  Updated: 29/Jan/11  Resolved: 07/Jan/11

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

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

Tags: 3-1-regression, 3_1-approved

 Description   

click on: server - JMS Physical Destination - New - Name: myTopic - Save

--------------------
HTTP Status 404 -

type Status report

message

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

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

This is a regression in recent build.



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

The regression is probably introduced when fixing previous cancel button issue.
The fix for this is trivial. The action is performed, just the redirect link at the end wasn't formed correctly. While looking into this, I see that the Save button in the edit page doesn't behave like other edit page. It should give the 'Save Successful' msg and stay at the same edit page. Instead, it goes back to the list page. So, i change that also.

After fixing all this, I notice that some of the value that user enters before pressing SAVE isn't really saved. It goes back to the previous value.
This includes the following fields:

  • Threshold Limit Behavior dropdown
  • Maximum Number of Producers
  • Use Dead Message Queue
  • Validate XML Schema

I will fix the redirect link and the SAVE with consistent behavior now.

Comment by Anissa Lam [ 03/Jan/11 ]

The fix isn't complete. Please refer to the previous comment.

1. How bad is its impact? (Severity)
Very bad as it shows 404 error on the GUI screen

2. How often does it happen? (Frequency)
everytime user press the Save button or Cancel button

3. How much effort is required to fix it? (Cost)
Pretty low. just need to fix the URL and print out the Save Successful msg upon Save. svn diff follows.

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

~/Awork/V3/v3/admingui 710) svn diff jms-plugin/
Index: jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationEdit.jsf
===================================================================
— jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationEdit.jsf (revision 44182)
+++ jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationEdit.jsf (working copy)
@@ -56,6 +56,7 @@
setPageSessionAttribute(key="edit" value="#

{true}");
getRequestValue(key="name" value=>$page{destName});
getRequestValue(key="type" value=>$page{destType});
+ setPageSessionAttribute(key="selfPage" value="#{request.contextPath}/jms/physdest/jmsPhysicalDestinationEdit.jsf?name=#{pageSession.destName}&type=#{pageSession.destType}&target=#{pageSession.target}&parentPage=#{pageSession.parentPage}")

if ("#{targetType} = instance") {
setPageSessionAttribute(key="baseUrl", value="#{sessionScope.REST_URL}/servers/server/#{pageSession.target}");
@@ -68,8 +69,8 @@
setPageSessionAttribute(key="valueMap", value="#{requestScope.restResponse.data.extraProperties.entity}");
/>
</event>
+ <sun:form id="jmsPhysDestForm">
#include "/common/shared/alertMsg.inc"
- <sun:form id="jmsPhysDestForm">
#include "jmsPhysicalDestinationSheet.inc"
<sun:hidden id="helpKey" value="$resource{helpjms.jmsPhysicalDestinationEdit}" />
</sun:form>
Index: jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationNew.jsf
===================================================================
— jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationNew.jsf (revision 44182)
+++ jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationNew.jsf (working copy)
@@ -54,6 +54,7 @@
setPageSessionAttribute(key="pageTitle" value="$resource{i18njms.jmsPhysDestinations.newPageTitle}");
setPageSessionAttribute(key="pageTitleHelp" value="$resource{i18njms.jmsPhysDestinations.newPageHelp}");
setPageSessionAttribute(key="parentPage" value="#{param.parentPage}");
+ println("======== parentPage = #{pageSession.parentPage}");
getDefaultPhysicalDestinationValues(map="#{pageSession.valueMap}");
setPageSessionAttribute(key="target" value="#{param.target}");

Index: jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationSheet.inc
===================================================================
— jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationSheet.inc (revision 44182)
+++ jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationSheet.inc (working copy)
@@ -66,7 +66,7 @@
gf.restRequest(endpoint="#{baseUrl}/create-jmsdest", method="post", attrs="#{requestScope.attrsMap}", result="#{requestScope.result}");

// updatePhysicalDestination(name="#{pageSession.destName}", type="#{pageSession.destType}", attributes="#{pageSession.valueMap}");
- gf.redirect(page="#{pageSession.parentPage}&target=#{pageSession.target}");
+ gf.redirect(page="#{request.contextPath}/#{pageSession.parentPage}");
/>
</sun:button>
<sun:button id="updateButton" rendered="#{edit}" text="$resource{i18n.button.Save}"
@@ -79,16 +79,16 @@
mapPut(map="#{requestScope.attrsMap}", key="desttype", value="#{pageSession.destType}");
mapPut(map="#{requestScope.attrsMap}", key="target", value="#{pageSession.target}");
mapPut(map="#{requestScope.attrsMap}", key="id", value="#{pageSession.valueMap.Name}");
-
+ prepareSuccessfulMsg();
gf.restRequest(endpoint="#{baseUrl}/__update-jmsdest", method="post", attrs="#{requestScope.attrsMap}", result="#{requestScope.result}");

// updatePhysicalDestination(name="#{pageSession.destName}", type="#{pageSession.destType}", attributes="#{pageSession.valueMap}");
- gf.redirect(page="#{pageSession.parentPage}&target=#{pageSession.target}");
+ gf.redirect(page="#{pageSession.selfPage}&alertType=${alertType}&alertSummary=${alertSummary}&alertDetail=${alertDetail}")
/>
</sun:button>
<sun:button id="cancelButton" immediate="#{true}

" text="$resource

{i18n.button.Cancel}

" primary="#

{false}

">
<!command

  • gf.redirect(page="# {pageSession.parentPage}&target=#{pageSession.target}");
    + gf.redirect(page="#{request.contextPath}/#{pageSession.parentPage}

    ");
    />
    </sun:button>

Comment by Jason Lee [ 04/Jan/11 ]

These changes look good to me. Let's commit this, then look at the unsaved attributes issue.

Comment by Anissa Lam [ 04/Jan/11 ]

My changes checked in. Still need to look at why some fields is not saved.

Log Message:
------------
GLASSFISH-15396. This is only partial fix to the issue. Fix redirect link after saving/cancel from new/edit JMS phys dest. page. Some field is not saved during editing. Still need to work on that.
Approver: Anissa
Reviewer: Jason.

Revisions:
----------
44207

Modified Paths:
---------------
trunk/v3/admingui/jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationEdit.jsf
trunk/v3/admingui/jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationNew.jsf
trunk/v3/admingui/jms-plugin/src/main/resources/physdest/jmsPhysicalDestinationSheet.inc

Comment by Jason Lee [ 05/Jan/11 ]

The issue with the attributes not saving seems to be in the JMSDestination class in the JMS Admin module. I've added support for the missing attributes (by comparing the code and MBean as I see in jconsole). Diff and CR below:

1. How bad is its impact? (Severity)
Moderate, as there is no easy way for a user to update these fields

2. How often does it happen? (Frequency)
Everytime

3. How much effort is required to fix it? (Cost)
Fairly low

4. What is the risk of fixing it? (Risk)
Seems to be pretty low to me as existing support is unchanged. I will, though, get a review from the JMS team to make sure I'm not missing something subtle.

Diff:

Index: jms/admin/src/main/java/org/glassfish/jms/admin/cli/JMSDestination.java
===================================================================
— jms/admin/src/main/java/org/glassfish/jms/admin/cli/JMSDestination.java (revision 44225)
+++ jms/admin/src/main/java/org/glassfish/jms/admin/cli/JMSDestination.java (working copy)
@@ -551,7 +551,7 @@
throw jae;
}
//XXX: To refactor into a Generic attribute type mapper, so that it is extensible later.

  • protected AttributeList convertProp2Attrs(Properties destProps)
    Unknown macro: {+ protected AttributeList convertProp2Attrs(Properties destProps) { AttributeList destAttrs = new AttributeList(); @@ -623,10 +623,37 @@ } else if (propName.equals("ConsumerFlowLimit")) { destAttrs.add(new Attribute("ConsumerFlowLimit", Long.valueOf(destProps.getProperty("ConsumerFlowLimit")))); + } else if (propName.equals("LocalDeliveryPreferred")) { + destAttrs.add(new Attribute("LocalDeliveryPreferred", + getBooleanValue(destProps.getProperty("LocalDeliveryPreferred")))); + } else if (propName.equals("ValidateXMLSchemaEnabled")) { + destAttrs.add(new Attribute("ValidateXMLSchemaEnabled", + getBooleanValue(destProps.getProperty("ValidateXMLSchemaEnabled")))); + } else if (propName.equals("UseDMQ")) { + destAttrs.add(new Attribute("UseDMQ", + getBooleanValue(destProps.getProperty("UseDMQ")))); + } else if (propName.equals("LocalOnly")) { + destAttrs.add(new Attribute("LocalOnly", + getBooleanValue(destProps.getProperty("LocalOnly")))); + } else if (propName.equals("ReloadXMLSchemaOnFailure")) { + destAttrs.add(new Attribute("ReloadXMLSchemaOnFailure", + getBooleanValue(destProps.getProperty("ReloadXMLSchemaOnFailure")))); + } else if (propName.equals("MaxNumProducers")) { + destAttrs.add(new Attribute("MaxNumProducers", + Integer.valueOf(destProps.getProperty("MaxNumProducers")))); + } else if (propName.equals("MaxNumBackupConsumers")) { + destAttrs.add(new Attribute("MaxNumBackupConsumers", + Integer.valueOf(destProps.getProperty("MaxNumBackupConsumers")))); + } else if (propName.equals("LimitBehavior")) { + destAttrs.add(new Attribute("LimitBehavior", + destProps.getProperty("LimitBehavior"))); } }

    return destAttrs;
    }

-
-}
+ private Boolean getBooleanValue(String propValue)

{ + return propValue.equalsIgnoreCase("true") ? Boolean.TRUE : Boolean.FALSE; +// UseDMQ + }

+}
\ No newline at end of file

Comment by Anissa Lam [ 05/Jan/11 ]

Approved for 3.1

Comment by Jason Lee [ 07/Jan/11 ]

Final fix committed (r44305)

Comment by Harshad Vilekar [ 29/Jan/11 ]

Verified in B-39.





[GLASSFISH-15392] [PERF] CDR Input Stream performance has regressed Created: 30/Dec/10  Updated: 03/Dec/12  Resolved: 06/Jan/11

Status: Closed
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: 3.1_ms08

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-13573 [PERF] Huge regression with trade2 be... Closed
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
Tags: 3_1-approved, PSRBUG

 Description   

The performance of CDRInputStream has significantly regressed, affected client-side and server-side performance. It is more visible on the client-side, where there isn't so much other logic going on to mask the issues.

Reading 5K simple requests takes 2X longer on 3.1 than 3.0.1 in CDRInputStream_1_0.readOctet(). This appears to be due to new locking semantics; in 3.0.1 the major component of reading is simply getting the data (HeapByteBuffer.get()), while in 3.1 we spend a large amount of time (half the total time, or essentially all the regression) waiting for locks around SynchronizedContent.content(). This only gets worse as we scale to more users on larger hardware.



 Comments   
Comment by Ken Cavanaugh [ 30/Dec/10 ]

I think you mean SynchronizedHolder.content. Is making the data member
_content volatile significantly faster than a lock in this case?
That probably still gives adequate semantics in this case.
Is this fix needed for 3.1, or can it be delayed until 3.2?

Comment by Scott Oaks [ 30/Dec/10 ]

I did mean SynchronizedHolder.content().

So I assume from the class type of the content variable that this is doing method-level tracing or monitoring? Even though we haven't turned that on? Part of the reason behind my question is that I'm not sure that the content() method itself is the issue or if the JDK has inlined enough things so that content().enter() is part of the bottleneck. But I assume not; I assume that "enter" refers to method tracing rather than monitor (meaning lock) acquisition.

I am not sure about volatile in this context; in general when locking around a getter method is a problem, the issue is the flushing of registers and such that are required by the Java memory model, and those semantics are the same for volatile. Though one difference might be that synchronized must make all references consistent and volatile only that particular reference, so there is room for improvement with volatile; I just don't know how smart the JVM is in that case. Barring that, could the monitor object be gotten once at the beginning of the request rather than for each little operation down the line? If the monitoring object is changed mid-request, you'd lose some info for that request, I guess, but it seems like that wouldn't be a big deal.

If I could turn of the monitoring somehow, I could give you a better answer as to the timing of the fix. Right now, this is the only difference in 3.0.1 and 3.1 I see on the server side to explain our trade2 regressions, so I expect it will be deemed significant enough to require a fix in 3.1. On the client side it is definitely affecting specj as well, but until there is a fix for 15391 we are unlikely to notice it there.

Comment by Ken Cavanaugh [ 30/Dec/10 ]

Monitoring is off. The instrumented code is just doing a SynchronizedHolder.content(), storing the value
(normally null) in a local, and checking the local value. However, it seems that the synchronization is more
expensive than I expected in this. It is not possible to do this per-request, because the tracing code
works per-class, and many classes are involved in a request.

Is the problem lock contention, or simply the number of lock calls? If it is lock contention, I could try a
read/write lock here, which would at least reduce contention, but may not help if the problem is just
the number of lock calls.

One complete fix for this would be to instrument the code at runtime. I've designed the tracing facility with
that in mind, so that part of the bytecode transformation (changing signatures of methods, creating or extending
the static initializer) must be done at build time, but the other part (which includes the SynchronizedHolder
call) could be done only when tracing is enabled. I'm reluctant to introduce that change this late in 3.1,
but it may be a good candidate for 3.2.

Another possibility is to simply remove the synchronization completely for 3.1, since normally
we only set tracing by -Dcom.sun.corba.ee.Debug=XXX, and so we don't rely on dynamically updating
very much, although it is possible through an ORB MBean.

So, we could try any of three approaches:

  • Remove the lock
  • Replace lock with volatile
  • Use read/write lock

I'm leaning in the direction of removing synchronization completely, and moving to the runtime instrumentation
solution for 3.2. Let me know which patch you want to try, and I'll put it together on a b019 ORB on 1/3/11.

Comment by Scott Oaks [ 30/Dec/10 ]

I think we should test a patch with the synchronization removed and see the effect. Then we can evaluate the better course once we know the impact, but if the monitor isn't going to be used dynamically, then that sounds like a good choice.

Comment by Ken Cavanaugh [ 06/Jan/11 ]

Performance regression should be fixed in ORB b021, integrated in GF rev 44286.





[GLASSFISH-15391] [PERF] Client-Side ORB requests have 3x performance regression Created: 30/Dec/10  Updated: 03/Dec/12  Resolved: 06/Jan/11

Status: Closed
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b35
Fix Version/s: 3.1_ms08

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File orb.tgz    
Issue Links:
Dependency
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
Tags: 3_1-approved, PSRBUG

 Description   

Rich client ORB requests have regressed in general as much as 3x due to the client-side libraries.

The profile for 3.X show that as the request is being sent, it makes its way down to com.sun.corba.ee.impl.interceptors.ClientRequestInfoImpl.getEffectiveComponents(). In 3.0.1, that takes a very small amount of time (.09 seconds in our test), and its major contributor is OMGSystemException.invalidComponentId (.038 seconds).

In 3.1, that leads into $Proxy.invalidComponentId() which itself takes 17.4 seconds for the same number of requests (5k). That call goes through CompositeInvocationHandlerImpl.invoke() and then into the logex.WrapperGenerator.



 Comments   
Comment by Ken Cavanaugh [ 31/Dec/10 ]

The basic problem here is a bad decision in the design of the PortableInterceptor API: there is no standard
API for checking whether or not a given IOR contains a tagged component with a particular ID, other than to
call get_effective_component(s) and catch the exception if no component with the ID is present. This affects
GF 3.1 in the JTS InterceptorImpl class, where send_request calls get_effective_component, and just ignores
a null result.

The code in the ORB's ClientRequestInfoImpl.get_effective_components implementation always throws an
exception when no tagged component with the given ID is present. I think I may modify this method so that
when the ORB is running in GF, it simply returns a null. This violates the OMG PI specification, but
it is probably a good solution in the specific case of the ORB in GF. I thought I made such a
modification long ago, but I can't find it now.

As a separate issue, I may look into dynamic code generation for the exception wrappers in 3.2, avoiding the
considerable overhead imposed by using dynamic proxies. But in any case, avoiding the throw of an exception
that is always ignored (for every request not using transactions) is a bad design regardless of the
efficiency of the underlying exception handling mechanism.

Comment by Ken Cavanaugh [ 03/Jan/11 ]

I've attached a version of the ORB that won't through an exception when
get_effective_components can't find the ID: it returns null instead.
This version also remove the synchronization in SynchronizedHolder that
seems to be causing the regression in 15392.

Comment by Ken Cavanaugh [ 04/Jan/11 ]

I've fixed the problem in get_effective_component (it threw NPE if
get_effective_components return null) and updated the orb.tgz file.

Comment by Ken Cavanaugh [ 06/Jan/11 ]

Performance regression should be fixed in ORB b021, integrated in GF rev 44286.





[GLASSFISH-15390] __list-group-names needs to take in target Created: 30/Dec/10  Updated: 03/Jan/11  Resolved: 03/Jan/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Issue Links:
Dependency
blocks GLASSFISH-15371 edit file realm thats NOT in server-c... Closed
Tags: 3_1-approved

 Description   

Usage: asadmin [asadmin-utility-options] __list-group-names
--realmname <realmname> --username <username>
[?|-help[=<help(default:false)>]]

There is no way to specify target for __list-group-names command.

As a result, it only looks into "server-config", and any file Realm created in other config will get error.

GUI is depending on this fix to allow user management for any file Realm in any config other than server-config.



 Comments   
Comment by kumarjayanti [ 30/Dec/10 ]

How bad is its impact? (Severity)
Major

How often does it happen? Will many users see this problem? (Frequency)
It appears Admin GUI is blocked on this bug

How much effort is required to fix it? (Cost)
minor - 2 java files changed.

What is the risk of fixing it and how will the risk be mitigated? (Risk)
No risk

Comment by Tom Mueller [ 03/Jan/11 ]

Approved for 3.1.

Comment by kumarjayanti [ 03/Jan/11 ]

fixed





[GLASSFISH-15384] need to add manifest Class-Path entry in en jar files Created: 29/Dec/10  Updated: 30/Dec/10  Resolved: 30/Dec/10

Status: Closed
Project: glassfish
Component/s: i18n
Affects Version/s: None
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

Some of the EN jar files need to have a manifest Class-Path entry to the corresponding l10n jar file.
Currently, only admin-cli has a reference to admin-cli-l10n; admin-cli-l10n then references the other l10n jars.
The better approach is that every JAR file that has a corresponding l10n jar would add the corresponding l10n.jar file to its Class-Path.



 Comments   
Comment by gmurr [ 29/Dec/10 ]

How bad is its impact? (Severity)
Affects every locale.

How often does it happen?
Everytime an localized message is loaded

Will many users see this problem? (Frequency)
all l10n users
How much effort is required to fix it? (Cost)
1 day

Comment by Chris Kasso [ 29/Dec/10 ]

Approved for 3.1

Comment by gmurr [ 30/Dec/10 ]

Fix integrated





[GLASSFISH-15375] Doing a POST to property of auth-realm doesn't remove previous property Created: 28/Dec/10  Updated: 29/Dec/10  Resolved: 29/Dec/10

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

This is what i saw when working on another bug related to auth-realm. I don't think this is a bug in REST, since this behavior only occurs for auth-realm. I am filing this in REST so you can confirm REST is ok and the bug is in security code. Please transfer to security if this is the case.

In every other case, eg. web container, this works fine.
But in auth-realm, it is 'adding' the new property specified instead of completely replace them.

Here is the endpoint:
"http://localhost:4848/management/domain/configs/config/server-config/security-service/auth-realm/file/property"
Here is the 'raw data' when doing the POST.

"[

{"selected":false,"description":"","name":"BBB","value":"BBB-value"}

,

{"name":"file","value":"$\{com.sun.aas.instanceRoot\}\/config\/keyfile"}

,

{"name":"jaas-context","value":"fileRealm"}

]"

Before the post, domain.xml has:

<auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="file">
<property name="file" value="$

{com.sun.aas.instanceRoot}/config/keyfile"></property>
<property name="jaas-context" value="fileRealm"></property>
<property name="AAA" value="AAA-value"></property>
</auth-realm>

After the POST, domain.xml has:
<auth-realm classname="com.sun.enterprise.security.auth.realm.file.FileRealm" name="file">
<property name="file" value="${com.sun.aas.instanceRoot}

/config/keyfile"></property>
<property name="jaas-context" value="fileRealm"></property>
<property name="AAA" value="AAA-value"></property>
<property name="BBB" value="BBB-value"></property>
</auth-realm>

I will expect the property "AAA" to be gone.

Here is the step to reproduce this in GUI:

  • go to Configs -> server-config -> Security -> Realms in the tree and click on 'file'.
  • add a property named "AAA" and value "AAA-value"
  • SAVE.

go to common task page and then back to this page, (or look at domain.xml), this shows the property is added correctly .

Now, remove property "AAA" and add another property named "BBB" with "BBB-value". Save.

You will see that both "AAA" and "BBB" exists.
There is no way to remove old property.



 Comments   
Comment by Jason Lee [ 29/Dec/10 ]

The handling of these properties goes through the same code path as all of the other ../property/ operations. When POSTing, all existing properties are cleared by getting a list of the child properties, calculating the dotted name for the property, then calling set with a blank value for the property. The new properties are then added back via the same code path, but with actual values passed.

In this case, I see the properties ('AAA') listed to be cleared, but I'm not seeing the property actually being removed. A work-around, though, is to use DELETE ../property/AAA which I have verified does work. This requires, though, special handling on the console, which is undesirable.

Reassigning to the admin team to investigate the interaction of the set command with the auth-realms. From the hip, we're sending a list of properties to clear, and it might be that one property (say 'fileRealm') is required and can't be cleared, so the set command is aborting. If that's the case, either set needs to be made less eager to quit, or the REST layer needs to call set iteratively rather than passing every property in one call. That approach is less efficient, but will likely be more reliable. I'll wait for feedback from the admin team to see which approach should be taken, assuming my guess is correct.

Comment by Jason Lee [ 29/Dec/10 ]

I'm going to take this back. As I've thought more on it, I think the best solution is to modify the behavior of the REST interface. I think my hunch that we're seeing some sort of constraint on the auth realm makes more sense (though I'd still like to know for sure). Modifying the code in the REST layer to delete one at a time is trivial, and I don't think any extra processing incurred as a result of the repeated calls to set will be noticeable by the end user.

Comment by Jason Lee [ 29/Dec/10 ]

How bad is its impact? (Severity)

Moderate. Unwanted properties would require a very manual process by the end user with either asadmin or a text editor, which is a suboptimal user experience.

How often does it happen? Will many users see this problem? (Frequency)

Every time

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

Very little.

What is the risk of fixing it and how will the risk be mitigated? (Risk)

There is little to no risk in fixing this.

Diff:

Index: admin/rest/src/main/java/org/glassfish/admin/rest/resources/PropertiesBagResource.java
===================================================================
— admin/rest/src/main/java/org/glassfish/admin/rest/resources/PropertiesBagResource.java (revision 44144)
+++ admin/rest/src/main/java/org/glassfish/admin/rest/resources/PropertiesBagResource.java (working copy)
@@ -207,9 +207,8 @@
protected void deleteExistingProperties() throws TransactionFailure {
HashMap<String, String> data = new HashMap<String, String>();
for (final Dom existingProp : parent.nodeElements(tagName))

{ + data.clear(); data.put (((ConfigBean) existingProp).attribute("name"), ""); - }
  • if (!data.isEmpty()) { Util.applyChanges(data, uriInfo, habitat); }

    }

Comment by Chris Kasso [ 29/Dec/10 ]

Approved for 3.1

Comment by Jason Lee [ 29/Dec/10 ]

Fix committed (r44154)





[GLASSFISH-15372] __supports-user-management needs to take in target Created: 28/Dec/10  Updated: 30/Dec/10  Resolved: 30/Dec/10

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Issue Links:
Dependency
blocks GLASSFISH-15371 edit file realm thats NOT in server-c... Closed
Tags: 3_1-approved

 Description   

There is no way to specify target for __supports-user-management command.

Usage: asadmin [asadmin-utility-options] __supports-user-management
-realmname <realmname> [?|--help[=<help(default:false)>]]
Command __supports-user-management failed.

As a result, it only looks into "server-config", and any file Realm created in other config will get error.

GUI is depending on this fix to allow user management for any file Realm in any config.



 Comments   
Comment by kumarjayanti [ 29/Dec/10 ]

How bad is its impact? (Severity)
Critical

How often does it happen? Will many users see this problem? (Frequency)
It appears Admin GUI is blocked on this bug

How much effort is required to fix it? (Cost)
minor - 2 java files changed.

What is the risk of fixing it and how will the risk be mitigated? (Risk)
No risk

Comment by Tom Mueller [ 29/Dec/10 ]

Approved for 3.1

Comment by kumarjayanti [ 29/Dec/10 ]

fixed

Comment by srinik76 [ 29/Dec/10 ]

__list-group-names should accept target option. For this I am re opening this issue. If you want to create a new issue please let me know.

Comment by srinik76 [ 30/Dec/10 ]

Closing this issue, created another issue to track this (15390)





[GLASSFISH-15369] can't create SSL socket Created: 28/Dec/10  Updated: 06/Jan/11  Resolved: 06/Jan/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1_b02, 3.1_ms01, 3.1_b03, 3.1_b05, 3.1_b06, 3.1_ms02, 3.1_b07, 3.1_b08, 3.1_b10, 3.1_ms03, 3.1_b12, 3.1_b13, 3.1_b14, 3.1_b15, 3.1_b16, 3.1_ms04, 3.1_b17, 3.1_b18, 3.1_b19, 3.1_b20, 3.1_ms05, 3.1_b21, 3.1_b22, 3.1_b23, 3.1_b24, 3.1_b25, 3.1_b26, 3.1_ms06, 3.1_b27, 3.1_b28, 3.1_b29, 3.1_b30, 3.1_b31, 3.1_b32, 3.1_ms07, 3.1_b33
Fix Version/s: 3.1_ms08

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

Mac OSX


Tags: 3_1-approved

 Description   

Take a look at this link: http://www.java.net/forum/topic/glassfish/glassfish/gf-v31-error-when-sending-email-using-smtps.
I also try try using the Glassfish-provided capabilities to configure Javamail as JNDI resource via JavaMail Session.
with:
MailHost: smtp.gmail.com
Transport Portocol: smtps
Transport Protocol Class: com.sun.mail.smtp.SMTPSSLTransport

Additional Property

mail-smtps-auth: true
mail-smtps-password: xxxx;



 Comments   
Comment by Bill Shannon [ 03/Jan/11 ]

This isn't a JavaMail-specific bug. Any attempt to create an SSL socket fails.
The following statement fails in a trivial servlet:

javax.net.ssl.SSLSocketFactory.getDefault().createSocket();

It fails with this exception:

Exception java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl)

Something about the security/SSL/JSSE configuration is causing this problem.

Comment by kumarjayanti [ 04/Jan/11 ]

The root cause is :

----------------------
Caused by: java.security.UnrecoverableKeyException: Password must not be
null
at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:107)
at
sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:38)
at java.security.KeyStore.getKey(KeyStore.java:763)
at
com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:113)
at
com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:48)
at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:239)
at
--------------------------

The users MDB is trying to send an email over SMTPS.

There has been a change since V2.X in that our Admin no longer sets the javax.net.ssl.keyStorePassword and javax.net.ssl.trustStorePassword system properties in V3.1 for good reasons.

Instead applications deployed on V3.1 are expected to use (this was also available in V2.X) :

HttpsURLConnection.getDefaultSSLSocketFactory();

to obtain the correct SSLSocketFactory to be used.

So i am wondering if there can be some change done in

com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:275)

Where it seems to call :

javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:102)

Comment by kumarjayanti [ 04/Jan/11 ]

The alternative workaround for application developers would be to manually add the following two jvm-options to their server configuration (domain.xml)

-Djavax.net.ssl.keyStorePassword=<GF-MasterPassword>
-Djavax.net.ssl.trustStorePassword=<GF-MasterPassword>

Comment by kumarjayanti [ 04/Jan/11 ]

developers need to use workaround for V3.1

Comment by kumarjayanti [ 04/Jan/11 ]

The security team could explore in the next release if there is someway to make

javax.net.ssl.SSLSocketFactory.getDefault()

do the right thing in the absence of those system properties.

Comment by kumarjayanti [ 04/Jan/11 ]

In terms of what else is possible in the security code apart from setting HttpsURLConnection.setDefaultSSLSocketFactory(...);, it appears we can try to call setDefault on SSLContext (not sure if it will interfere with deployed apps making secure outbound connections in other ways).

SSLContext ctx = .....
SSLContext.setDefault(ctx);

so that SSLContext.getDefault().getSocketFactory() will return the right socket factory.

But i believe calling SSLContext.setDefault(ctx) will have no impact on the result of javax.net.ssl.SSLSocketFactory.getDefault() ?. Need to check this out.

The following thread seems to suggest WebLogic too requires users to use something special rather than SocketFactory.getDefault():

http://objectmix.com/java/76856-sslsocketfactory-getdefault-vs-sslcontext-getsocketfactory.html

Comment by Nazrul [ 04/Jan/11 ]

This seems like a serious compatibility issue. If applications can no longer make secure connections without changing their code, it is a show stopper for 3.1. Please investigate further. At a minimum, you will need CCC approval if there are no other alternatives.

Comment by kumarjayanti [ 05/Jan/11 ]

1) How bad is its impact? (Severity)

Breaks JavaMail SSL outbound connection from an Application deployed on GlassFish

2) How often does it happen? (Frequency)
Only outbound SSL connections from Appserver are effected if the app/framework used by the App uses :
javax.net.ssl.SSLSocketFactory.getDefault().createSocket();

3) How much effort is required to fix it? (Cost)
Minor : the fix is to add a single line of code in SSLUtils.
SSLContext.setDefault(ctx);

4) What is the risk of fixing it? (Risk)
There can be some impact for apps with this fix. But the risks have been discussed with Bill. The plan is to document the guidelines on how Apps acting as SSL Clients should obtain SSLSocketFactory for Outbound SSL Connections.

Comment by Chris Kasso [ 05/Jan/11 ]

Approved for 3.1

Comment by kumarjayanti [ 06/Jan/11 ]

fixed





[GLASSFISH-15361] Integrate bundled doc changes from cross-check of final UI Created: 27/Dec/10  Updated: 28/Dec/10  Resolved: 28/Dec/10

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

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

Tags: 3_1-approved

 Description   

After hard code freeze (HCF), the doc team cross-checked the UI against the OLH and man pages and updated these documents to reflect the changes. This issue is a request to integrate the changes to the man pages and OLH.

How bad is its impact? (Severity)
Medium to high.

How often does it happen? Will many users see this problem? (Frequency)
Moderately frequently. Any user that reads an affected man page or OLH screen will see this problem.

How much effort is required to fix it? (Cost)
Very little. The change is a one-line change to a single POM file. Most of the effort involved is in testing the integration.

What is the risk of fixing it and how will the risk be mitigated? (Risk)
Level of risk: low.
Mitigation: build, test, spot check the changes, and run quick look tests before integration.



 Comments   
Comment by Paul Davies [ 28/Dec/10 ]

Fix committed in revision 44123.





[GLASSFISH-15360] stop-cluster man page is out of date Created: 27/Dec/10  Updated: 28/Dec/10  Resolved: 28/Dec/10

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

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


 Description   

stop-cluster man page talks about --autohadboverride and does not talk about --kill option.

NAME
stop-cluster - stops a GlassFish Server cluster

SYNOPSIS
stop-cluster [--help]
[--verbose=

{false|true}

]
[--autohadboverride=

{true|false}

] cluster-name

Usage from implementation:
% asadmin stop-cluster -x

Usage: asadmin [asadmin-utility-options] stop-cluster
[-kill[=<kill(default:false)>]] [-verbose[=<verbose(default:false)>]]
[?|-help[=<help(default:false)>]] clustername



 Comments   
Comment by Paul Davies [ 27/Dec/10 ]

Description of --kill was added to the version that will be integrated in milestone 8.

--autohadboverride is deliberately left in the SYNOPSIS to avoid giving the impression that specifying it causes the command to fail.

The description of this option in the OPTIONS section instructs the user not to specify this option and states that option is retained for compatibility with earlier releases and is ignored.

This description is compatible with the behavior of the command:

asadmin stop-cluster --autohadboverride=true ymlcluster
CLI031 Warning: Option "autohadboverride" is obsolete and will be ignored.
Command stop-cluster executed successfully.

All obsolete options are handled this way.

Comment by Paul Davies [ 28/Dec/10 ]

Fixed in revision 44123.





[GLASSFISH-15356] Invalid README at the top level install directory Created: 27/Dec/10  Updated: 28/Dec/10  Resolved: 27/Dec/10

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Applies to all operating systems.


Tags: 3_1-approved

 Description   

After installation, OpenInstaller's README file ends up at the top level of installation directory.
This file should either be removed or replaced with glassfish specific README file.



 Comments   
Comment by scatari [ 27/Dec/10 ]

Since we are not bundling a product level README, this file should be removed.

1. How bad is its impact? (Severity)
Gives useless information to the users who would open up README file immediately after installation.

2. How often does it happen? (Frequency)
Everytime the product is installed successfully through the installer.

3. How much effort is required to fix it? (Cost)
2 days as a new version of OpenInstaller binaries(Engine and Resources) without the README file have to be hosted. This README file comes from OpenInstaller binaries.

4. What is the risk of fixing it? (Risk)
Less risky as only the framework version will be upgraded without any other changes to installer or framework binaries themselves. The change would involve removing README from engine.zip and resource.zip and rehosting the new zip files as new binary versions of OpenInstaller.

Comment by scatari [ 27/Dec/10 ]

Removed the README from engine and resources binaries of OpenInstaller and included the new version of these binaries in installer's pom.xml.

Fix reviewed by Snjezana.
Fix approved by Nazrul.

Comment by scatari [ 28/Dec/10 ]

Fix verified successfully in B35-12_28_2010 nightly build. The README file has been removed.





[GLASSFISH-15352] Encrypted key does not work on Windows for setup-ssh, install-node, uninstall-node Created: 27/Dec/10  Updated: 28/Dec/10  Resolved: 28/Dec/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 3.1_ms08

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

Windows Cygwin, Windows MKS


Tags: 3_1-approved

 Description   

setup-ssh, install-node, uninstall-node fail to work on Windows if encrypted keys are used:

[C:/yamini/gf/glassfish3/glassfish/bin] ./asadmin setup-ssh --sshuser Yamini u>
Enter SSH password for Yamini@underpass.india.sun.com>
SSH key setup failed: Publickey authentication failed.
Command setup-ssh failed.



 Comments   
Comment by Yamini K B [ 27/Dec/10 ]

How bad is its impact? (Severity)
Severe since user will not be able to use encrypted keys at all with these commands. Though key without passphrase will work, users concerned about strict security will not be able to use these commands if they have encrypted key.

How often does it happen? Will many users see this problem? (Frequency)
Always.

How much effort is required to fix it? (Cost)
Newline char is hard coded (as '\n') while parsing the key file to detect encrypted keys. It's just a 2-line fix to use line.separator instead.

What is the risk of fixing it and how will the risk be mitigated? (Risk)
Low risk since it doesn't affect other uses cases of the commands.

Comment by Tom Mueller [ 27/Dec/10 ]

Approved for 3.1.

Comment by Yamini K B [ 28/Dec/10 ]

Fixed in r44113





[GLASSFISH-15351] FindBugs issue in security/jaspic-provider-framework Created: 27/Dec/10  Updated: 18/Jan/11  Resolved: 18/Jan/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

Type: Bug Priority: Minor
Reporter: kumarjayanti Assignee: kumarjayanti
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved

 Description   

monzillo: security/jaspic-provider-framework/src/main/java/com/sun/jaspic/config/factory/BaseAuthConfigFactory.java:141: UL_UNRELEASED_LOCK: com.sun.jaspic.config.factory.BaseAuthConfigFactory.getConfigProvider(String, String, RegistrationListener) does not release lock on all paths
monzillo: security/jaspic-provider-framework/src/main/java/com/sun/jaspic/config/factory/BaseAuthConfigFactory.java:143: UL_UNRELEASED_LOCK: com.sun.jaspic.config.factory.BaseAuthConfigFactory.getConfigProvider(String, String, RegistrationListener) does not release lock on all paths



 Comments   
Comment by kumarjayanti [ 27/Dec/10 ]

To pacify findbugs the fix seems to be move the code into another method and restructure as follows :

@Override
public AuthConfigProvider
getConfigProvider(String layer, String appContext,
RegistrationListener listener) {
AuthConfigProvider provider = null;
if (listener == null) {
rLock.lock();
try

{ provider = getConfigProviderUnderLock(layer,appContext,null); }

finally

{ rLock.unlock(); }

} else {
wLock.lock();
try

{ provider = getConfigProviderUnderLock(layer,appContext,listener); }

finally

{ wLock.unlock(); }

}
return provider;
}

Comment by kumarjayanti [ 27/Dec/10 ]

How bad is its impact? (Severity)
minor

How often does it happen? (Frequency)
There is no real bug here as we understand, it is just that FindBugs complains about the code as incorrect locking pattern. So we have to restructure the code a bit to pacify findbugs.

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

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

When i tried to push back on fixing this, Bill shannon insisted that one of the goals was to ship with zero findbugs.

Comment by kumarjayanti [ 28/Dec/10 ]

moving to 3.2 since it was not approved for 3.1

Comment by kumarjayanti [ 18/Jan/11 ]

Fixed.





[GLASSFISH-15350] Thread Id is coming different in server.log file Created: 26/Dec/10  Updated: 26/Oct/12  Due: 29/Dec/10  Resolved: 26/Oct/12

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

Type: Bug Priority: Critical
Reporter: naman_mehta Assignee: sandeep.shrivastava
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

All Platform


Attachments: Java Source File TestServlet.java    
Tags: 3_1-approved

 Description   

If user starts domain using following command

./asadmin start-domain --debug --verbose
It starts domain properly with all required thread ids in logging message.

On console user can see following message with Thread Id 60.
[#|2010-12-27T11:20:28.114+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=60;_ThreadName=Thread-25;|Binding RMI port to *:8686|#]

[#|2010-12-27T11:20:28.705+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=60;_ThreadName=Thread-25;|JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://naman:8686/jndi/rmi://naman:8686/jmxrmi|#]

But when you open and see server.log file same messages is logged with different thread Id 17.
[#|2010-12-27T11:20:28.114+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=17;_ThreadName=Thread-1;|Binding RMI port to *:8686|#]

[#|2010-12-27T11:20:28.705+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=17;_ThreadName=Thread-1;|JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://naman:8686/jndi/rmi://naman:8686/jmxrmi|#]



 Comments   
Comment by naman_mehta [ 26/Dec/10 ]

How bad is its impact? (Severity)
Major. You can find wrong thread Ids in log messages in server.log file.

How often does it happen? Will many users see this problem? (Frequency)
Regularly. Yes.

How much effort is required to fix it? (Cost)
Need to remove current thread id from logging message during formating the log message. As it's not needed.

What is the risk of fixing it and how will the risk be mitigated? (Risk)
No risk. Just removing thread Id from log message. Attached the file diff for the same.

File diff:
Index: src/main/java/com/sun/enterprise/server/logging/UniformLogFormatter.java
===================================================================
— src/main/java/com/sun/enterprise/server/logging/UniformLogFormatter.java (revision 44094)
+++ src/main/java/com/sun/enterprise/server/logging/UniformLogFormatter.java (working copy)
@@ -246,9 +246,7 @@
recordBuffer.append(record.getLoggerName()).append(FIELD_SEPARATOR);

recordBuffer.append("_ThreadID").append(NV_SEPARATOR);

  • record.setThreadID((int) Thread.currentThread().getId());
    + //record.setThreadID((int) Thread.currentThread().getId());
    recordBuffer.append(record.getThreadID()).append(NVPAIR_SEPARATOR);

recordBuffer.append("_ThreadName").append(NV_SEPARATOR);

Should I make this changes.

After fixing above issue. You can find following messages on console and server.log. Both having same Message Ids.

On Console:
[#|2010-12-27T11:27:41.937+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=65;_ThreadName=Thread-28;|Binding RMI port to *:8686|#]

[#|2010-12-27T11:27:42.326+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=65;_ThreadName=Thread-28;|JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://naman:8686/jndi/rmi://naman:8686/jmxrmi|#]

In server.log:
[#|2010-12-27T11:27:41.937+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=65;_ThreadName=Thread-1;|Binding RMI port to *:8686|#]

[#|2010-12-27T11:27:42.326+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=65;_ThreadName=Thread-1;|JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://naman:8686/jndi/rmi://naman:8686/jmxrmi|#]

Comment by Nazrul [ 27/Dec/10 ]

Requested Carla and Jerome to review this change

Comment by Nazrul [ 27/Dec/10 ]

Would the above change re-introduce the following issue: http://java.net/jira/browse/GLASSFISH-11813

Comment by Nazrul [ 28/Dec/10 ]

According to Naman, issue GLASSFISH-11813 is not re-introduced with the above fix. Approved for checkin.

Comment by naman_mehta [ 28/Dec/10 ]

Made check ins for the same.

Committed revision 44133.

Comment by Sanjeeb Sahoo [ 09/Jul/12 ]

I am amazed by the lack of attention to details. This bug is still not fixed. Whilist the threadId is printed correctly, the thread name is still incorrect.

Comment by naman_mehta [ 09/Jul/12 ]

The issue is due to LogRecord is storing thread ID and which is used during formatting the log message but the thread Name is not available at the same time. Need to assign thread name based on thread id.

Comment by Sanjeeb Sahoo [ 09/Jul/12 ]

Thread name can't be obtained from threadId. So, if we really want thread name to be reported, then it must be put into log record in the same thread that tries to log message.

Comment by sandeep.shrivastava [ 26/Jul/12 ]

The java.util.logging.LogRecord object does not allow for capturing additional request metadata that is later available in another thread at the time of writing the record to the log file. A possible fix for this issue could be to write to the log file in the original thread that initiated the logging request. The log file rotation can still be done asynchronously.

Thoughts? Comments?

Comment by rajendra_inamdar [ 27/Jul/12 ]

One way to handle this could be to create a custom LogRecord where additional contextual information can be stored. It can be put on the queue. This info can be used during formatting when the custom LogRecord is processed in the consumer thread.

Comment by rajendra_inamdar [ 24/Aug/12 ]

Fix submitted:

r55516 | rajendra.inamdar@oracle.com | 2012-08-16 13:34:31 -0700 (Thu, 16 Aug 2012) | 2 lines
Changed paths:
M /trunk/main/nucleus/core/logging/src/main/java/com/sun/enterprise/server/logging/GFFileHandler.java
A /trunk/main/nucleus/core/logging/src/main/java/com/sun/enterprise/server/logging/GFLogRecord.java
M /trunk/main/nucleus/core/logging/src/main/java/com/sun/enterprise/server/logging/ODLLogFormatter.java
M /trunk/main/nucleus/core/logging/src/main/java/com/sun/enterprise/server/logging/UniformLogFormatter.java

Fix incorrect thread-name in the server log records.

Comment by Bobby Bissett [ 05/Oct/12 ]

What is the status of this issue now that a patch was submitted? The incorrect thread names in the log file caused us a great deal of confusion on our project. If it helps, am attaching a test servet that shows the problem. Here is the output I see:

Using GF 2.1.1-b31:

Terminal output:
[#|2012-10-05T09:58:12.998-0400|INFO|sun-appserver2.1|testLogger|_ThreadID=18;_ThreadName=bobby_test_thread;|Hi, I am bobby_test_thread|#]
Log:
[#|2012-10-05T09:58:12.998-0400|INFO|sun-appserver2.1|testLogger|_ThreadID=18;_ThreadName=bobby_test_thread;|Hi, I am bobby_test_thread|#]

Using GF 3.1.2.2:

Terminal output:
[#|2012-10-05T10:02:06.340-0400|INFO|glassfish3.1.2|testLogger|_ThreadID=20;_ThreadName=bobby_test_thread;|Hi, I am bobby_test_thread|#]
Log:
[#|2012-10-05T10:02:06.340-0400|INFO|glassfish3.1.2|testLogger|_ThreadID=20;_ThreadName=Thread-3;|Hi, I am bobby_test_thread|#]

Clearly, the log file record for GF 3.X should match the others.

Comment by rajendra_inamdar [ 26/Oct/12 ]

This issue is fixed in 4.0. As per SE advice, marking this one fixed and opened a bugdb issue.

On 10/26/12 5:03 AM, manoj malhotra wrote:
>
> Hi All-
>
> SE works via bugdb only.
> Open a bug in bugdb and let me know, I can target it for 3.1.2-patch#4.
> Same (dev) engineer who has fixed bug for 4.0 need to backport it for SE tails.
>
> Kind Regards,
> Manoj

Comment by Bobby Bissett [ 26/Oct/12 ]

Is there any way I can get a patch (or pointer to the commit and I'll find the files) so I can rebuild my 3.1.2.2 with this change?





[GLASSFISH-15348] Fix productRoot, installRoot usages in install/uninstall-node Created: 26/Dec/10  Updated: 29/Dec/10  Resolved: 29/Dec/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 3.1_ms08

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

All


Tags: 3_1-approved

 Description   

1. In uninstall-node, installdir default value should be productRoot, not installRoot
2. productRoot is derived as installroot/../ at some places, this needs to be fixed



 Comments   
Comment by Nazrul [ 28/Dec/10 ]

If we don't fix this, would install-node/uninstall-node work in conjunction? For example, if user take defaults for install-node, would uninstall-node fail if user take the default values?

Comment by Yamini K B [ 28/Dec/10 ]

install-node picks up the correct default value for --installdir, so the problem is only with uninstall-node's default value.

Btw, #2 mentioned in description doesn't cause any problem.

Comment by Yamini K B [ 28/Dec/10 ]

How bad is its impact? (Severity)
Not severe but its a usability issue if default value doesn't work.

How often does it happen? Will many users see this problem? (Frequency)
Happens only when user doesn't use --installdir with uninstall-node

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

What is the risk of fixing it and how will the risk be mitigated? (Risk)
Low risk

Comment by Nazrul [ 28/Dec/10 ]

Approved for checkin

Comment by Yamini K B [ 29/Dec/10 ]

Fixed in r44159





[GLASSFISH-15346] create-auth-realm command failed for jdbcrealm? when executed on a fresh instance Created: 24/Dec/10  Updated: 26/Dec/10  Resolved: 26/Dec/10

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

sonia reported :

I did a fresh installation, started domain and derby, then ran the command, it failed. Please note that I did not run any test before trying this command.

  1. /export/sonia/v3/glassfish3/glassfish/bin/asadmin create-auth-realm --classname com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm --property jaas-context=jdbcRealm:datasource-jndi=jdbc/s1qeDB:user-table=usertable:user-name-column=userid:password-column=password:group-table=grouptable:group-name-column=groupid:digest-algorithm=MD5 --target server realmperapp1
    org.glassfish.api.admin.CommandException: remote failure: Creation of Authrealm realmperapp1 failed. java.lang.NullPointerException
    java.lang.NullPointerException
    Command create-auth-realm failed.

I used the latest nightly build 12/21. There was no errors/exceptions in server.log. Which build did you use?



 Comments   
Comment by kumarjayanti [ 24/Dec/10 ]

This failure occurs if someone creates JDBCRealm on a clean instance where no apps have been deployed.

I debugged and found out the reason (at line 171 we call Util.getDefaultHabitat().getByContract(...) and Util.getDefaultHabitat() is actually NULL).

[#|2010-12-24T22:25:35.339+0530|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=20;_ThreadName=Thread-1;|java.lang.NullPointerException
at com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm.init(JDBCRealm.java:171)
at com.sun.enterprise.security.auth.realm.Realm.doInstantiate(Realm.java:335)
at com.sun.enterprise.security.auth.realm.Realm.instantiate(Realm.java:226)
at com.sun.enterprise.security.SecurityConfigListener.createRealm(SecurityConfigListener.java:386)
at com.sun.enterprise.security.SecurityConfigListener.authRealmCreated(SecurityConfigListener.java:263)
at com.sun.enterprise.security.cli.CreateAuthRealm$1.run(CreateAuthRealm.java:191)
at com.sun.enterprise.security.cli.CreateAuthRealm$1.run(CreateAuthRealm.java:182)
at org.jvnet.hk2.config.ConfigSupport$1.run(ConfigSupport.java:115)
at org.jvnet.hk2.config.ConfigSupport._apply(ConfigSupport.java:174)
at org.jvnet.hk2.config.ConfigSupport.apply(ConfigSupport.java:133)
at org.jvnet.hk2.config.ConfigSupport.apply(ConfigSupport.java:112)
at com.sun.enterprise.security.cli.CreateAuthRealm.execute(CreateAuthRealm.java:182)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)

Comment by kumarjayanti [ 24/Dec/10 ]

How bad is its impact? (Severity) -
Major

How often does it happen? Will many users see this problem? (Frequency)
Blocking smooth run of Security QE tests

How much effort is required to fix it? (Cost)
1 file affected -1 line of code added (see diff below)

What is the risk of fixing it and how will the risk be mitigated? (Risk)
no risks

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

— src/main/java/com/sun/enterprise/security/cli/CreateAuthRealm.java (revision 44084)
+++ src/main/java/com/sun/enterprise/security/cli/CreateAuthRealm.java (working copy)
@@ -63,6 +63,7 @@
import com.sun.enterprise.config.serverbeans.Domain;
import com.sun.enterprise.config.serverbeans.Server;
import com.sun.enterprise.security.SecurityConfigListener;
+import com.sun.enterprise.security.common.Util;
import com.sun.enterprise.util.LocalStringManagerImpl;

import com.sun.enterprise.util.SystemPropertyConstants;
@@ -132,6 +133,10 @@
private Domain domain;
@Inject
private SecurityConfigListener securityListener;
+
+ //initialize the habitat in Util needed by Realm classes
+ @Inject
+ private Util util;

Comment by Nazrul [ 24/Dec/10 ]

Approved for checkin

Comment by kumarjayanti [ 26/Dec/10 ]

fixed in latest trunk





[GLASSFISH-15340] [Regression] SEVERE error message logged when creating new JMS Connection Factory Created: 23/Dec/10  Updated: 03/Feb/11  Resolved: 28/Dec/10

Status: Closed
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1_b34
Fix Version/s: 3.1_ms08

Type: Bug Priority: Minor
Reporter: Harshad Vilekar Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3-1-regression, 3_1-approved

 Description   

Steps:

  • Create new JMS Connection Factory on JMS Resources GUI screen:

Resources - JMS Resources -Connection Factories - New
Pool Name: jms_ConnectionFactory
Resource Type: javax.jms.ConnectionFactory
Click on OK

  • server log shows "Cannot find values in set command model, file a bug"
  • This was not seen in earlier builds - hence marking as a regression.
                        • server log ---------------
                          [#|2010-12-23T12:12:55.888-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=91;_ThreadName=admin-thread-pool-4848(2);|***** pageSession.valueMap = {lazyConnectionAssociation=false, connectionCreationRetryIntervalInSeconds=10, maxConnectionUsageCount=0, connectionCreationRetryAttempts=0, associateWithThread=false, lazyConnectionEnlistment=false, idleTimeoutInSeconds=300, matchConnections=true, steadyPoolSize=8, connectioLeakReclaim=false, connectionLeakTimeoutInSeconds=0, pooling=true, maxPoolSize=32, isConnectionValidationRequired=false, failAllConnections=false, maxWaitTimeInMillis=60000, ping=false, poolResizeQuantity=2}

                          |#]

[#|2010-12-23T12:13:27.459-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin|_ThreadID=105;_ThreadName=admin-thread-pool-4848(6);|Cannot find values in set command model, file a bug|#]

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



 Comments   
Comment by Harshad Vilekar [ 27/Dec/10 ]

Same message is logged when updating/saving already created ConnectionFactory.

Comment by Jason Lee [ 28/Dec/10 ]

How bad is its impact? (Severity)

Minor. No functionality is impaired. It's only a message in the log, though may possibly lead to support questions.

How often does it happen? Will many users see this problem? (Frequency)

Every time

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

Very little

What is the risk of fixing it and how will the risk be mitigated? (Risk)

Very little risk

Diff:

Index: src/main/java/org/glassfish/admin/rest/resources/PropertiesBagResource.java
===================================================================
— src/main/java/org/glassfish/admin/rest/resources/PropertiesBagResource.java (revision 44114)
+++ src/main/java/org/glassfish/admin/rest/resources/PropertiesBagResource.java (working copy)
@@ -182,7 +182,9 @@
data.put (property.get("name") + ".description", description);
}
}

  • Util.applyChanges(data, uriInfo, habitat);
    + if (!data.isEmpty()) { + Util.applyChanges(data, uriInfo, habitat); + }

String successMessage = localStrings.getLocalString("rest.resource.update.message",
"\"

{0}

\" updated successfully.", new Object[]

{uriInfo.getAbsolutePath()}

);

Comment by Anissa Lam [ 28/Dec/10 ]

I reviewed the code, looks fine.
Approved to checkin.

Comment by Jason Lee [ 28/Dec/10 ]

Fix committed (r44117)

Comment by Harshad Vilekar [ 03/Feb/11 ]

Verified. 3.1 Build 41 nightly.





[GLASSFISH-15337] Running with Sec Mgr Enabled: failed permission check for "findMBeanServer" Created: 23/Dec/10  Updated: 12/Jan/11  Resolved: 12/Jan/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_ms08

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

Solaris 10 / Ultra 45 / JDK 1.6.0_22


Attachments: File server.log.findMBeanServer    

 Description   

This issue comes out of issue: GLASSFISH-15299

It was recommended that I pull one of the items out of GF issue 15299 and make it into a separate issue assigned to admin/JMX.

The issue involves running with Security Manager Enabled. After discussions, it was decided that since tasks being executed are common tasks a typical user might due, users should not be expected to have to update the server.policy file for doing those common tasks. Instead, it should be handled on the GF server side.

The Failed Permission Check is:
javax.management.MBeanServerPermission findMBeanServer

The CTS Test that generates this is:
src/com/sun/ts/tests/ejb30/assembly/appres/warejb

Attached is an excerpt from server.log output that contains the details of the failed permission check including a stack trace.

-phendley



 Comments   
Comment by prasads [ 28/Dec/10 ]

This seems to occur when we call the findMBeanServer from the JPA and possibly because its not being called in a doPriviledged block. Adding a line to the server.policy may be a workaround , but not a solution. Can we get a fix from the JPA folks ?

Comment by kumara [ 28/Dec/10 ]

Reopen for evaluation by entity persistence folks.

Comment by Mitesh Meswani [ 01/Jan/11 ]

A fix is being worked on in EclipseLink.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=333336 tracks the corresponding EclipseLink issue.

Comment by Mitesh Meswani [ 03/Jan/11 ]

The fix from EclipseLink is scheduled to be pulled in with next integration of EclipseLink (currently scheduled for Jan 12th)

Comment by Mitesh Meswani [ 12/Jan/11 ]

Fixed with integration of EclipseLink 2.2-RC2





[GLASSFISH-15336] findbugs : DLS_DEAD_LOCAL_STORE: Dead store to resourceConfigurations Created: 23/Dec/10  Updated: 23/Dec/10  Resolved: 23/Dec/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: None
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/module/ResourcesDeployer.java:478: DLS_DEAD_LOCAL_STORE: Dead store to resourceConfigurations in com.sun.enterprise.connectors.module.ResourcesDeployer.createAppScopedResources(Application, List, DeploymentContext, boolean)



 Comments   
Comment by Jagadish [ 23/Dec/10 ]

1. How bad is its impact? (Severity)
Minor.
2. How often does it happen? (Frequency)
During deployment, but does not have major impact.
3. How much effort is required to fix it? (Cost)
Remove unused variable.
4. What is the risk of fixing it? (Risk)
No risk, all tests pass - QL (Web, Classic), connector-dev, jdbc-dev, connector-standalone-cts (Web, Classic), resources-admin-cli

Comment by Chris Kasso [ 23/Dec/10 ]

Approved for 3.1

Comment by Jagadish [ 23/Dec/10 ]

svn log -v -r 44068

Modified Paths:
---------------
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/module/ResourcesDeployer.java





[GLASSFISH-15333] Create and Edit http values under protocol has inconsistency in the attribute values Created: 23/Dec/10  Updated: 06/Jan/11  Resolved: 06/Jan/11

Status: Resolved
Project: glassfish
Component/s: command_line_interface, rest-interface
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Attachments: Text File aliases.patch     PNG File createhttp.png     PNG File edithttp.png    
Tags: 3_1-approved

 Description   

Creation of http under protocol ->REST URL http://localhost:4848/management/domain/configs/config/server-config/network-config/protocols/protocol/http-listener-2/create-http

has the following http attributes
DefaultVirtualServer*: ,dns-lookup-enabled: ,max-connection: ,request-timeout-seconds: ,servername: ,target: ,timeout-seconds: ,xpowered:

Editing http under protocol -> REST Url http://localhost:4848/management/domain/configs/config/server-config/network-config/protocols/protocol/admin-listener/http

defaultVirtualServer*: ,dnsLookupEnabled: ,maxConnections: ,requestTimeoutSeconds:,
serverName:,timeoutSeconds: ,xpoweredBy:

Attaching the Rest Interface GUI Screen shots



 Comments   
Comment by Jason Lee [ 27/Dec/10 ]

The issue here is a mismatch between the AdminCommand parameters and the ConfigBean attributes. This mismatched can be fixed by adding the alias attribute to the @Param instances on the AdminCommand. Requesting the admin team to make the appropriate changes

Comment by Tom Mueller [ 28/Dec/10 ]

This appears to be related to a Grizzly config bean.
Reassigning to the Grizzly category.

Comment by oleksiys [ 28/Dec/10 ]

reassigning to Justin

Comment by Anissa Lam [ 28/Dec/10 ]

We realize that GUI only create HTTP with the target value, and then edit it with the attribute value that user entered.
So, GUI really doesn't depend on the fix of this bug to fix the GUI bug GLASSFISH-15326.
I am changing this to P3 and removing the dependency link.

Comment by Justin Lee [ 06/Jan/11 ]

1. How bad is its impact? (Severity)
Minor. Discrepancy between names might confuse some users.

2. How often does it happen? (Frequency)
Potentially any time some one creates/edits one of these elements using the REST interface.

3. How much effort is required to fix it? (Cost)
Little. Patch is attached.

4. What is the risk of fixing it? (Risk)
Low. It overloads the meaning/use of the alias on a @Param but apparently it was Bill Shannon's suggestion so he's comfortable with it at least.

Comment by Anissa Lam [ 06/Jan/11 ]

Approved.

Comment by Justin Lee [ 06/Jan/11 ]

changes for http://java.net/jira/browse/GLASSFISH-15332 and http://java.net/jira/browse/GLASSFISH-15333

Reviewed by: Ludo
Approved by: Anissa

File summary : 2 files affected in 1 modules.
Modules affected : admin

Module [admin]:
2 Modified files:
src/main/java/org/glassfish/web/admin/cli/CreateHttp.java 40201=>44284
src/main/java/org/glassfish/web/admin/cli/CreateNetworkListener.java 40201=>44284

Committed at Jan 6, 2011 6:22:15 PM





[GLASSFISH-15332] Create and Edit network listener has inconsistency in the attribute values Created: 22/Dec/10  Updated: 06/Jan/11  Resolved: 06/Jan/11

Status: Resolved
Project: glassfish
Component/s: command_line_interface, rest-interface
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Attachments: Text File aliases.patch     PNG File createnwlistener.png     PNG File editnwlistener.png    
Tags: 3_1-approved

 Description   

REST URL : http://localhost:4848/management/domain/configs/config/server-config/network-config/network-listeners/network-listener

Create network listener has attribute values as

Port*:
address:
enabled:
id*:
jkenabled:
protocol*:
target:
threadpool:
transport:

Edit network listener has attribute values as

address:
enabled:
jkConfigurationFile:
jkEnabled:
name*:
port*:
protocol*:
threadPool:
transport*:

Because of above inconsistency, during network listener creation jkEnabled, threadPool does not get saved.

Please find attached the GUI Rest interface screen for create and update network listener



 Comments   
Comment by Jason Lee [ 27/Dec/10 ]

The issue here is a mismatch between the AdminCommand parameters and the ConfigBean attributes. This mismatched can be fixed by adding the alias attribute to the @Param instances on the AdminCommand. Requesting the admin team to make the appropriate changes

Comment by Tom Mueller [ 28/Dec/10 ]

This appears to be related to a Grizzly config bean (NetworkListener?)
Reassigning to the Grizzly team.

Comment by oleksiys [ 30/Dec/10 ]

reassigning to Justin

Comment by Anissa Lam [ 06/Jan/11 ]

I took a closer look in GUI code and believe it is actually a bug in GUI itself. It will be nice if the create/edit attribute name match, but thats not the real cause.
Discussed with Srini and he made the fix in GUI code now.

Hence, GUI doesn't require this bug fix. I have removed the dependency link and downgrade this to P3. The backend team can decide if this bug should be fixed for 3.1.

Comment by Jason Lee [ 06/Jan/11 ]

I still think this should be fixed for 3.1, as it affects a public interface for the system. There are quite possibly other inconsistencies like this in the system, but we know about this one and it's an easy change to make, so I see no reason not to do it. Hopefully, 3.2 will bring us a better approach to this.

Comment by Justin Lee [ 06/Jan/11 ]

So is there anything to do on this one if the bug is in the GUI code? Should it be reassigned/closed?

Comment by Anissa Lam [ 06/Jan/11 ]

The bug in GUI code is not related to this. We will fix the GUI bug. Don't assign this bug to me

However, just like Jason mention, you should fix this inconsistency reported in this bug as it is an easy fix.

Comment by Justin Lee [ 06/Jan/11 ]

if it weren't for that change control process, i'd agree... and grouse less.

Comment by Justin Lee [ 06/Jan/11 ]

1. How bad is its impact? (Severity)
Minor. Discrepancy between names might confuse some users.

2. How often does it happen? (Frequency)
Potentially any time some one creates/edits one of these elements using the REST interface.

3. How much effort is required to fix it? (Cost)
Little. Patch is attached.

4. What is the risk of fixing it? (Risk)
Low. It overloads the meaning/use of the alias on a @Param but apparently it was Bill Shannon's suggestion so he's comfortable with it at least.

Comment by Anissa Lam [ 06/Jan/11 ]

Approved.

Comment by Justin Lee [ 06/Jan/11 ]

changes for http://java.net/jira/browse/GLASSFISH-15332 and http://java.net/jira/browse/GLASSFISH-15333

Reviewed by: Ludo
Approved by: Anissa

File summary : 2 files affected in 1 modules.
Modules affected : admin

Module [admin]:
2 Modified files:
src/main/java/org/glassfish/web/admin/cli/CreateHttp.java 40201=>44284
src/main/java/org/glassfish/web/admin/cli/CreateNetworkListener.java 40201=>44284

Committed at Jan 6, 2011 6:22:15 PM





[GLASSFISH-15328] Admin Console doesn't show new or removed file realm user until server restart Created: 22/Dec/10  Updated: 06/Jan/11  Resolved: 24/Dec/10

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: 3.1_ms08

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


 Description   

I'm trying to follow the instructions in the Java EE 6 Tutorial, "To Set Up Your System for Running the Security Examples", http://download.oracle.com/javaee/6/tutorial/doc/bncbx.html#gjjlk.

I am using the nightly glassfish-3.1-b34-12_21_2010.zip installed on Solaris 10.

I go to Configurations->default-config->Security->Realms->file, click Manage Users, then click New to add a new user to the file realm.

I fill in the fields and click OK. I am immediately returned to the File Users page, but the new user does not appear in the File Users table. The server log says,

[#|2010-12-22T17:30:59.973-0500|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=81;_ThreadName=admin-thread-pool-4848(1);|***** users = []|#]

The asadmin command reports that the user exists, however:

jdench 51 =>asadmin list-file-users
myid
Command list-file-users executed successfully.

The user doesn't show up when I refresh the page or reload the Admin Console. However, if I stop and restart the server and then load the Admin Console, the user does show up.

[#|2010-12-22T17:39:49.717-0500|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=93;_ThreadName=admin-thread-pool-4848(3);|***** users = [

{name=myid, groups=[TutorialUser]}]|#]

Similarly, if I then select the user, click the Delete button, and click OK in the confirmation dialog, the user is not removed from the table.

[#|2010-12-22T17:40:18.808-0500|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=99;_ThreadName=admin-thread-pool-4848(5);|SEC1117: Realm [file] successfully updated.|#]

[#|2010-12-22T17:40:18.998-0500|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=98;_ThreadName=admin-thread-pool-4848(4);|***** users = [{name=myid, groups=[TutorialUser]}

]|#]

The user is actually gone:

jdench 53 =>asadmin list-file-users
Command list-file-users executed successfully.

But I have to stop and restart the server to make the user disappear from the File Users table.



 Comments   
Comment by Anissa Lam [ 22/Dec/10 ]

Hi Kim,
when you use CLI to list the user name, you need to give the target, which is the config name.
In your steps above, you are working on 'default-config', yet, not specifying the config name in the CLI, which will gives you the uesr from 'server-config'.

As you point out, when server restarts, it shows up. this means GUI is passing in the config name correctly during creation, but backend doesn't have the user name shows up until server restart.

The cli command to list file user is:

Usage: asadmin [asadmin-utility-options] list-file-users
[--authrealmname <authrealmname>] [?|-help[=<help(default:false)>]]
[target]

you didn't specify the realm name, and didn't specify the target in your CLI command above.
I don't know which realm the list-file-users will default to. but target will default to server-config.

If you specify your CLI as
%asadmin list-file-users --authrealmname file default-config

you will see the same thing from CLI.
I just tested that.

transfer the bug to security.
this maybe duplicate of http://java.net/jira/browse/GLASSFISH-15273

Comment by Nithya Ramakrishnan [ 23/Dec/10 ]

Appears like a duplicate of 15273.

Comment by kumarjayanti [ 24/Dec/10 ]

I tested with latest builds and all this works perfectly fine

Comment by Kim Haase [ 06/Jan/11 ]

Yes, I can confirm that the new user shows up immediately in the Admin Console at b35. Closing issue.





[GLASSFISH-15327] Protocol links in the Network Listeners table points always points to 'server-config' regardless what config you are working on Created: 22/Dec/10  Updated: 22/Dec/10  Resolved: 22/Dec/10

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

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

Tags: 3_1-review

 Description   

Create a new config, or go to "default-config".
go to Network Config -> Network Listeners page
The table shows the Network Listener, and there is the Protocol column and Thread pool column.
click on Protocol, It will go to the "server-config" 's protocol instead of the config you are working on.

click on Thread pool column, the same thing. goes to the wrong config.

This is very serious bug. Because, instead of modifying the listener on other config, you are modifying the listener of 'server-config' and may have very bad consequences.



 Comments   
Comment by Anissa Lam [ 22/Dec/10 ]

How bad is its impact? (Severity)
moderate. you will be taken over to edit server-config that may not be what you want.

How often does it happen? Will many users see this problem? (Frequency)
Everytime user goes to Network Listeners table and want to go to the protocol or threadpool that this listener is ref. to.

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

What is the risk of fixing it and how will the risk be mitigated? (Risk)
Risk is low. add the config param to the link.

Index: src/main/resources/grizzly/networkListeners.jsf
===================================================================
— src/main/resources/grizzly/networkListeners.jsf (revision 44036)
+++ src/main/resources/grizzly/networkListeners.jsf (working copy)
@@ -160,11 +160,11 @@
</sun:tableColumn>

<sun:tableColumn headerText="$resource

{i18n_web.grizzly.table.protocolCol}

" sort="protocol" rowHeader="$boolean

{true}" id="pro">
- <sun:hyperlink id="link" text="#{td.value.protocol}" url="#{request.contextPath}/web/grizzly/protocolEdit.jsf?name=#{td.value.protocol}&cancelTo=networkListeners.jsf" />
+ <sun:hyperlink id="link" text="#{td.value.protocol}" url="#{request.contextPath}/web/grizzly/protocolEdit.jsf?name=#{td.value.protocol}&cancelTo=networkListeners.jsf&configName=#{pageSession.configName}" />
</sun:tableColumn>

<sun:tableColumn headerText="$resource{i18n_web.grizzly.table.threadPoolCol}" sort="threadPool" rowHeader="$boolean{true}

" id="threadPool">

  • <sun:hyperlink id="link" text="# {td.value.threadPool}" url="#{request.contextPath}/web/configuration/threadPoolEdit.jsf?name=#{td.value.threadPool}

    &cancelTo=grizzly/networkListeners.jsf" />
    + <sun:hyperlink id="link" text="#

    {td.value.threadPool}" url="#{request.contextPath}/web/configuration/threadPoolEdit.jsf?name=#{td.value.threadPool}

    &cancelTo=grizzly/networkListeners.jsf&configName=#

    {pageSession.configName}

    " />
    </sun:tableColumn>

<sun:tableColumn headerText="$resource

{i18n_web.grizzly.table.enabledCol}

" sort="enabled" rowHeader="$boolean

{true}

" id="col22">

Comment by srinik76 [ 22/Dec/10 ]

Reassigning to you as you are working on this

Comment by Anissa Lam [ 22/Dec/10 ]

Here is the commit. I just realize i put in the reviewer name wrong.
Should be Srini.

========================
Project: glassfish
Repository: svn
Revision: 44058
Author: anilam
Date: 2010-12-23 07:38:42 UTC
Link:

Log Message:
------------
GLASSFISH-15327. Add config name for the links in network listeners table to go to the correct config.
Approver: Anissa
Reviewer: Siraj.

Revisions:
----------
44058

Modified Paths:
---------------
trunk/v3/admingui/web/src/main/resources/grizzly/networkListenerAttr.inc
trunk/v3/admingui/web/src/main/resources/grizzly/networkListeners.jsf





[GLASSFISH-15323] JACC edit screen doesn't show any attribute value. Created: 22/Dec/10  Updated: 22/Dec/10  Resolved: 22/Dec/10

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

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

Issue Links:
Dependency
depends on GLASSFISH-14003 Edit jacc provider fails : attribute ... Resolved
Tags: 3_1-approved

 Description   

Go to any config -> Security -> JACC and edit any jacc , no attribute shows up.

Email from Srini mentioned Jason, assign to Jason to take a look.

==========================

On 12/22/10 3:12 AM, Srinivas Krishnan wrote:
> Hi Anissa,
>
> This was already a known issue in rest layer because of attribute
> inconsistency. I had raised a issue and assigned to Jason well before
> my vacation. I need to trace the Issue number it was bug tracking in
> java.net. Need to find what is the Issue number? I thought this was
> fixed.
>
> Regards
> Srinivas
> On Tue, 2010-12-21 at 23:42 -0800, Anissa Lam wrote:
>> Hi Srini,
>>
>> I see that the JACC edit screen wasn't able to display the 2 text field
>> for the provider class, can you take a look ?
>> java.net is down, so i can't file a bug now.
>> We have a 'global' issue where doing a SAVE has problem in many pages, i
>> am looking into that.
>>
>> thanks
>> Anissa.



 Comments   
Comment by Jason Lee [ 22/Dec/10 ]

How bad is its impact? (Severity)

Moderate. Users are unable to edit existing JACC providers.

How often does it happen? Will many users see this problem? (Frequency)

Every time.

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

Very little.

What is the risk of fixing it and how will the risk be mitigated? (Risk)

Almost none.

Diff:

Index: admingui/common/src/main/resources/security/jacc/jaccProvider.inc
===================================================================
— admingui/common/src/main/resources/security/jacc/jaccProvider.inc (revision 44029)
+++ admingui/common/src/main/resources/security/jacc/jaccProvider.inc (working copy)
@@ -39,7 +39,6 @@
holder.

-->
-
<sun:propertySheet id="propertySheet">
#include "/common/shared/configNameSection.inc"

@@ -51,10 +50,10 @@
<sun:textField id="IdText" text="#

{pageSession.valueMap['name']}

" columns="$int

{55}

" maxLength="#

{sessionScope.fieldLengths['maxLength.common.Name']}

" styleClass="required" required="#

{true}" />
</sun:property>
<sun:property id="policyConfigProp" labelAlign="left" noWrap="#{true}

" overlapLabel="#

{false}" label="$resource{i18nc.jacc.PolicyConfig}" helpText="$resource{i18nc.jacc.PolicyConfigHelp}">
- <sun:textField id="PolicyConfig" columns="$int{75}" maxLength="#{sessionScope.fieldLengths['maxLength.jacc.PolicyConfig']}" text="#{pageSession.valueMap['policyconfigfactoryclass']}" styleClass="required" required="#{true}"/>
+ <sun:textField id="PolicyConfig" columns="$int{75}" maxLength="#{sessionScope.fieldLengths['maxLength.jacc.PolicyConfig']}" text="#{pageSession.valueMap['policyConfigurationFactoryProvider']}" styleClass="required" required="#{true}"/>
</sun:property>
<sun:property id="policyProviderProp" labelAlign="left" noWrap="#{true}" overlapLabel="#{false}

" label="$resource

{i18nc.jacc.PolicyProvider}

" helpText="$resource

{i18nc.jacc.PolicyProviderHelp}

">

  • <sun:textField id="PolicyProvider" columns="$int {75}" maxLength="#{sessionScope.fieldLengths['maxLength.jacc.PolicyProvider']}" text="#{pageSession.valueMap['policyproviderclass']}" styleClass="required" required="#{true}"/>
    + <sun:textField id="PolicyProvider" columns="$int{75}

    " maxLength="#

    {sessionScope.fieldLengths['maxLength.jacc.PolicyProvider']}

    " text="#

    {pageSession.valueMap['policyProvider']}

    " styleClass="required" required="#

    {true}

    "/>
    </sun:property>
    </sun:propertySheetSection>
    </sun:propertySheet>

Comment by Anissa Lam [ 22/Dec/10 ]


code reviewed. please checkin.

Comment by Jason Lee [ 22/Dec/10 ]

Fix committed (r44047)





[GLASSFISH-15318] In non-DAS (cluster/instance), unable to fail undeployment of resource-adapter if resources of resource-adapter exist. Created: 22/Dec/10  Updated: 22/Dec/10  Resolved: 22/Dec/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: None
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

When "undeploy --cascade=false" is executed against a non-DAS target (instance/cluster) to undeploy an RAR and if there are resources of RAR undeploy must fail.

Currently, undeploy proceeds further and undeploys the resource-adapter and resources (not the configuration, but the runtime).

Fix is to fail undeploy in the above use-case and indicate the user that "undeploy --cascade=true" need to be used.



 Comments   
Comment by Jagadish [ 22/Dec/10 ]

Fix is available. Fix is needed from deployment and connector modules.

  • How bad is its impact? (Severity)
    Medium.
    Not fixing it will result in undeploying the resource-adapter (and the
    resources) in instances/clusters.
  • How often does it happen? Will many users see this problem? (Frequency)
    When all of the conditions hold true :
    a) "undeploy --cascade=false --target 'non-DAS' "
    b) resources of the resource-adapter are present.
  • How much effort is required to fix it? (Cost)
    Fix is to listen to "UNDEPLOYMENT_VALIDATION" event, mark for deployment failure in the above use-case and as a result
    undeploy will fail stating the user that "undeploy --cascade=true" must be used.
    All of QL (Web, Classic), deployment-dev, connector-dev, connector-standalone-cts (Web, Classic) pass.
    Tested the use-case with standalone-instances, clusters against resource-adapter as well embedded-resource-adapter.
Comment by Nazrul [ 22/Dec/10 ]

Approved for checkin

Comment by Jagadish [ 22/Dec/10 ]

FIX INFORMATION :
svn log -v -r 44054

Modified Paths:
---------------
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/module/ConnectorDeployer.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/server/ApplicationLifecycle.java
trunk/v3/connectors/connectors-runtime/src/main/resources/com/sun/enterprise/connectors/LocalStrings.properties
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/UndeployCommand.java
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/module/ConnectorApplication.java





[GLASSFISH-15309] User is not allowed to modify install/node dir but can clear it Created: 21/Dec/10  Updated: 04/Mar/11  Resolved: 29/Dec/10

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

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

build: ogs-3.1-b34-12_21_2010.zip


Issue Links:
Dependency
depends on GLASSFISH-15291 Cannot modify SSH node with instances Closed
Tags: 3_1-verified

 Description   

Create a CONFIG node in Admin Console specifying all fields correctly. Create an instance under the node. Now go to Edit Node screen and attempt to change the installation or node directory to some other, bogus value - you will get an error message saying that they cannot be modified - that's expected. Clear out both fields and hit save. Changes are saved without a warning. Subsequent attempt to create another instance fails because installdir attribute is not set. Admin Console should not allow to clear out those fields if there are any instances under the node.

The same issue exists with an SSH node that has instances - user can clear both node and install directory fields and save changes.



 Comments   
Comment by Anissa Lam [ 21/Dec/10 ]

Gui doesn't want to get into the logic whether a node can be modified based on runtime information. That kind of restriction needs to be enforced in the backend. This also ensures an uniform error across all clients and eliminates the needs for every client to implement the restriction.

Transfer to 'admin'.

Comment by carlavmott [ 22/Dec/10 ]

Will not fix in this release because we need to figure out how to handle the case where the user cleared the field as you did vs the GUI is sending us the empty string because the initial value was not set and we are to set it to the default value.

Comment by Joe Di Pol [ 28/Dec/10 ]

We can detect the clearing of an attribute that is already set. The fix for http://java.net/jira/browse/GLASSFISH-15291 can address this issue too.

Comment by Joe Di Pol [ 29/Dec/10 ]

Project: glassfish
Repository: svn
Revision: 44153
Author: jfdipol
Date: 2010-12-29 21:59:50 UTC
Link:

Log Message:
------------
15291 Cannot modify SSH node with instances when installdir is not changed
15309 User is not allowed to modify install/node dir but can clear it

Code Review: Carla Mott
Approver: Nazrul

Comment by lidiam [ 04/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-15306] [regression] Trying to create JMS Physical Destination Resource throws javax.el.PropertyNotFoundException: java.lang.IndexOutOfBoundsException Created: 21/Dec/10  Updated: 31/Jan/11  Resolved: 22/Dec/10

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

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

Solaris 10 Sparc, JDK6u23


Attachments: JPEG File jms-dest-resource.jpg    
Issue Links:
Duplicate
duplicates GLASSFISH-15310 Error while saving all pages in web-c... Closed
is duplicated by GLASSFISH-15329 Cannot set Default Principal to Role ... Resolved
Tags: 3-1-regression, 3_1-approved

 Description   

On Admin Console:

Click - Resources - JMS Resources - Destination Resources

JNDI Name: testJNDIName
Physical Destination Name: testPhysicalDest
Resource Type: javax.jms.Topic

Click OK.

Result: "An Error Has Occurred" message is displayed.

This worked ok on earlier 3.1 builds.

---------------- Server Log ---------------

[#|2010-12-21T15:11:49.114-0800|INFO|oracle-glassfish3.1|com.sun.jersey.server.impl.application.WebApplicationImpl|_ThreadID=79;_ThreadName=admin-thread-pool-4848(4);|Initiating Jersey application, version 'Jersey: 1.5-ea08 12/10/2010 02:57 PM'|#]

[#|2010-12-21T15:11:49.649-0800|INFO|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=79;_ThreadName=admin-thread-pool-4848(4);|Listening to REST requests at context: /monitoring/domain|#]

[#|2010-12-21T15:14:04.895-0800|INFO|oracle-glassfish3.1|javax.enterprise.resource.jms.com.sun.enterprise.connectors.jms.system|_ThreadID=144;_ThreadName=pool-39-thread-1;|ADDRESSLIST in setJmsServiceProvider: mq://localhost:7676/|#]

[#|2010-12-21T15:14:04.900-0800|INFO|oracle-glassfish3.1|javax.enterprise.resource.jms.com.sun.enterprise.connectors.jms.system|_ThreadID=144;_ThreadName=pool-39-thread-1;|JMS Service Connection URL is : mq://localhost:7676/|#]

[#|2010-12-21T15:14:06.158-0800|INFO|oracle-glassfish3.1|org.hibernate.validator.engine.resolver.DefaultTraversableResolver|_ThreadID=144;_ThreadName=pool-39-thread-1;|Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.|#]

[#|2010-12-21T15:14:06.503-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=144;_ThreadName=pool-39-thread-1;|**** Generated BTRACE Client com/sun/btrace/flashlight/BTrace_Flashlight_114|#]

[#|2010-12-21T15:14:06.968-0800|INFO|oracle-glassfish3.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=144;_ThreadName=pool-39-thread-1;|MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter: Version: 4.5 (Build 23-c) Compile: Sat Dec 18 19:18:13 PST 2010|#]

[#|2010-12-21T15:14:06.971-0800|INFO|oracle-glassfish3.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=144;_ThreadName=pool-39-thread-1;|MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter starting: broker is EMBEDDED, connection mode is Direct|#]

[#|2010-12-21T15:14:14.853-0800|INFO|oracle-glassfish3.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=144;_ThreadName=pool-39-thread-1;|MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter Started:EMBEDDED|#]

[#|2010-12-21T15:14:15.021-0800|SEVERE|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=80;_ThreadName=admin-thread-pool-4848(5);|RestResponse.getResponse() gives FAILURE. endpoint = 'http://localhost:4848/management/domain/resources/admin-object-resource/testJNDIName/property.json'; attrs = 'null'|#]

[#|2010-12-21T15:14:15.361-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=80;_ThreadName=admin-thread-pool-4848(5);|javax.el.PropertyNotFoundException: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at com.sun.webui.jsf.faces.DataProviderELResolver$ValueData.getValue(DataProviderELResolver.java:413)
at com.sun.webui.jsf.faces.DataProviderELResolver.getValue(DataProviderELResolver.java:159)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:116)
at com.sun.el.parser.AstValue.getValue(AstValue.java:163)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:219)
at com.sun.webui.jsf.component.TableRowGroup.isSelected(TableRowGroup.java:2979)
at com.sun.webui.jsf.renderkit.html.TableRowGroupRenderer.renderEnclosingTagStart(TableRowGroupRenderer.java:762)
at com.sun.webui.jsf.renderkit.html.TableRowGroupRenderer.encodeChildren(TableRowGroupRenderer.java:187)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at com.sun.webui.jsf.util.RenderingUtilities.renderComponent(RenderingUtilities.java:91)
at com.sun.webui.jsf.renderkit.html.TableRenderer.encodeChildren(TableRenderer.java:168)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1756)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at com.sun.webui.jsf.renderkit.html.ContentPageTitleRenderer.encodeChildren(ContentPageTitleRenderer.java:169)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:551)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:555)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.encode(LayoutComponent.java:243)
at com.sun.jsftemplating.layout.descriptors.LayoutInsert.encodeChildren(LayoutInsert.java:125)
at com.sun.jsftemplating.layout.descriptors.LayoutInsert.encodeThis(LayoutInsert.java:107)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:330)
at com.sun.jsftemplating.layout.descriptors.LayoutComposition.encodeThis(LayoutComposition.java:161)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:330)
at com.sun.jsftemplating.layout.descriptors.LayoutComposition.encodeThis(LayoutComposition.java:161)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:330)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutDefinition.encode(LayoutDefinition.java:246)
at com.sun.jsftemplating.layout.LayoutViewHandler.renderView(LayoutViewHandler.java:683)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:396)
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.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at com.sun.jsftemplating.component.dataprovider.MultipleListDataProvider.getObject(MultipleListDataProvider.java:130)
at com.sun.jsftemplating.component.dataprovider.MultipleListDataProvider.getSupport(MultipleListDataProvider.java:564)
at com.sun.jsftemplating.component.dataprovider.MultipleListDataProvider.getFieldKey(MultipleListDataProvider.java:260)
at com.sun.data.provider.impl.TableRowDataProvider.getFieldKey(TableRowDataProvider.java:113)
at com.sun.webui.jsf.faces.DataProviderELResolver$ValueData.getValue(DataProviderELResolver.java:399)
... 64 more

#]

[#|2010-12-21T15:14:15.369-0800|WARNING|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=80;_ThreadName=admin-thread-pool-4848(5);|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.IllegalStateException: PWC3991: getOutputStream() has already been called for this response
at org.apache.catalina.connector.Response.getWriter(Response.java:704)
at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:225)
at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:723)
at com.sun.faces.context.PartialViewContextImpl.createPartialResponseWriter(PartialViewContextImpl.java:424)
at com.sun.faces.context.PartialViewContextImpl.access$300(PartialViewContextImpl.java:71)
at com.sun.faces.context.PartialViewContextImpl$DelayedInitPartialResponseWriter.getWrapped(PartialViewContextImpl.java:575)
at javax.faces.context.PartialResponseWriter.startDocument(PartialResponseWriter.java:115)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handlePartialResponseError(AjaxExceptionHandlerImpl.java:200)
at com.sun.faces.context.AjaxExceptionHandlerImpl.handle(AjaxExceptionHandlerImpl.java:124)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:396)
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)



 Comments   
Comment by Jason Lee [ 22/Dec/10 ]

How bad is its impact? (Severity)

Severe. Affects multiple pages.

How often does it happen? Will many users see this problem? (Frequency)

Every time

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

Very little.

What is the risk of fixing it and how will the risk be mitigated? (Risk)

Very low.

Diff:

Index: src/main/java/org/glassfish/admin/rest/resources/PropertiesBagResource.java
===================================================================
— src/main/java/org/glassfish/admin/rest/resources/PropertiesBagResource.java (revision 44029)
+++ src/main/java/org/glassfish/admin/rest/resources/PropertiesBagResource.java (working copy)
@@ -140,14 +140,14 @@
@POST // create
@Consumes(

{MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML, MediaType.APPLICATION_FORM_URLENCODED})
@Produces({"text/html;qs=2", MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
- public Response createProperties(List<Map<String, String>> data) {
+ public ActionReportResult createProperties(List<Map<String, String>> data) { return clearThenSaveProperties(data); }

@PUT // create
@Consumes({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML, MediaType.APPLICATION_FORM_URLENCODED}

)
@Produces(

{"text/html;qs=2", MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}

)

  • public Response replaceProperties(List<Map<String, String>> data) {
    + public ActionReportResult replaceProperties(List<Map<String, String>> data) { return clearThenSaveProperties(data); }

@@ -169,7 +169,9 @@
}
}

  • protected Response clearThenSaveProperties(List<Map<String, String>> properties) {
    + protected ActionReportResult clearThenSaveProperties(List<Map<String, String>> properties) {
    + RestActionReporter ar = new RestActionReporter();
    + ar.setActionDescription("Property");
    try {
    deleteExistingProperties();
    Map<String, String> data = new LinkedHashMap<String, String>();
    @@ -184,15 +186,20 @@

String successMessage = localStrings.getLocalString("rest.resource.update.message",
"\"

{0}

\" updated successfully.", new Object[]

{uriInfo.getAbsolutePath()}

);

  • return ResourceUtil.getResponse(200, successMessage, requestHeaders, uriInfo);
    +
    + ar.setSuccess();
    + ar.setMessage(successMessage);
    } catch (Exception ex)
    Unknown macro: { if (ex.getCause() instanceof ValidationException) { - return ResourceUtil.getResponse(400, /*400 - bad request*/ - ex.getMessage(), requestHeaders, uriInfo); + ar.setFailure(); + ar.setFailureCause(ex); + ar.setMessage(ex.getLocalizedMessage()); } else { throw new WebApplicationException(ex, Response.Status.INTERNAL_SERVER_ERROR); } }

    +
    + return new ActionReportResult("properties", ar, new OptionsResult(Util.getResourceName(uriInfo)));
    }

protected void deleteExistingProperties() throws TransactionFailure {

Comment by Jason Lee [ 22/Dec/10 ]

Fix committed (r44034)

Comment by Anissa Lam [ 22/Dec/10 ]


code reviewed. looks fine. please checkin.

Comment by Harshad Vilekar [ 27/Dec/10 ]

Verified the fix with latest nightly build.

Comment by Harshad Vilekar [ 31/Jan/11 ]

Verified.





[GLASSFISH-15298] delete-jvm-options: - -profiler option missing from usage Created: 21/Dec/10  Updated: 21/Dec/10  Resolved: 21/Dec/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_ms08

Type: Bug Priority: Major
Reporter: Paul Davies Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved, 3_1-regression

 Description   

The --profiler option is missing from the custom usage message in the LocalStrings.properties file:

$ asadmin delete-jvm-options *
Command delete-jvm-options only accepts one operand
Usage: asadmin [asadmin-utility-options] delete-jvm-options
[--target <target(default:server)>] [?|-help[=<help(default:false)>]]
(jvm_option_name[=jvm_option_value])[:jvm_option_name[=jvm_option_name]]*

However, the subcommand supports this option and the option is present in the code.

Note that the manual page correctly includes this option.



 Comments   
Comment by Tom Mueller [ 21/Dec/10 ]

This is a regression from 2.1, as the delete-jvm-options usage message has the --profiler option listed.

As this is a regression and the fix is super simple, approving for 3.1.

Comment by Tom Mueller [ 21/Dec/10 ]

Note: the create-jvm-options command has the same issue.

Comment by Tom Mueller [ 21/Dec/10 ]

Fixed in revision 44009.





[GLASSFISH-15296] Error during Virtual server creation. Created: 21/Dec/10  Updated: 21/Feb/11  Resolved: 22/Dec/10

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

Type: Bug Priority: Critical
Reporter: shaline Assignee: Jason Lee
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Solaris SParc 10.
Browser : firefox 3.6


Tags: 3_1-regression, 3_1-verified

 Description   

GF build used : Nightly dated b34-12/21

In the Admin Console, tried to create a new Virtual server accepting all default values, as below:
host:$

{com.sun.aas.hostName}

State :On
SSO: Controlled by HTTP Service
Network Listener : http-listenr-1, http-listener-2
Log file :$

{com.sun.aas.instanceRoot}/logs/server.log
Docroot: ${com.sun.aas.instanceRoot}

/docroot
Access Logging : Controlled by HTTP Service
Directory :$

{com.sun.aas.instanceRoot}

/logs/access

Click OK button.

The below Error is thrown: :"An Error Has Occured"
Server.log has no Exceptions.

Even when we try to edit an existing VS, and click OK button, the above issue is seen.
This is a regression.



 Comments   
Comment by Jason Lee [ 22/Dec/10 ]

This is a duplicate of GLASSFISH-15306

Comment by shaline [ 25/Jan/11 ]

Verified in promoted b38.





[GLASSFISH-15291] Cannot modify SSH node with instances Created: 21/Dec/10  Updated: 30/Jan/11  Resolved: 29/Dec/10

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

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

build: ogs-3.1-b34-12_20_2010.zip


Issue Links:
Dependency
blocks GLASSFISH-15309 User is not allowed to modify install... Closed
Tags: 3_1-approved

 Description   

Create an SSH node with e.g. a key file. Add an instance to the node. Attempt to change the node from key file to password using force option. The following error is displayed:

An error has occurred
Warning: some parameters appear to be invalid. Could not connect to host vmbanta using SSH. Could not authenticate. Continuing with node update due to use of --force. Cannot update node vmb. It is in use by a server instance and therefore attribute installdir cannot be changed.

I did not update the installation directory field.



 Comments   
Comment by carlavmott [ 21/Dec/10 ]

You can not update a node if there are instances referring to it. It seems that you are trying to change the security setting is that right? Right now nothing can be changed.

Comment by Anissa Lam [ 21/Dec/10 ]

The restriction and thus the error is given by backend. Transfer to Carla.

Comment by lidiam [ 21/Dec/10 ]

I understand that I cannot modify two fields: installation directory and node directory if a node has instances. However, I should be able to modify other fields. I should be able to change authentication information on any node, if it has instances or not. Also, the second part of the error message is incorrect: I did not modify installdir.

Comment by carlavmott [ 22/Dec/10 ]

I have tried several tests using both the command line and the GUI and am able to change the fields.

Comment by carlavmott [ 22/Dec/10 ]

I can update the attributes of an ssh node if there is not passphrase set on the machine using the GUI.

I can update the attributes of an ssh node using the command line if there is a passphrase set but not using the gui. I'm transferring this back to anissa as I can not reproduce the error above but I do see an error.

Comment by Anissa Lam [ 23/Dec/10 ]

I am not sure what you mean by
"I can update the attributes of an ssh node using the command line if there is a passphrase set but not using the gui. I'm transferring this back to anissa as I can not reproduce the error above but I do see an error."

Can you tell me what you did in GUI ? maybe a screenshot just before you press SAVE will help.
What is the CLI command you use ?

For me, if i change to:
SSH User authentication: Password
and then enter password: abc
I am calling everything correctly.

There is the error from backend that says:
"Cannot update node newSSH. It is in use by a server instance and therefore attribute installdir cannot be changed"

Here is the log if you set the GUI logger to FINESE.

[#|2010-12-23T09:01:37.348-0800|FINEST|glassfish3.1|org.glassfish.admingui|_ThreadID=88;_ThreadName=admin-thread-pool-4848(5);ClassName=org.glassfish.admingui.common.util.RestUtil;MethodName=restRequest;|restRequest: endpoint=http://localhost:4848/management/domain/nodes/node/newSSH/update-node-ssh
attrs={sshkeyfile=, sshpassword=abc, installdir=$

{com.sun.aas.productRoot}, nodedir=, force=false, sshport=22, nodehost=localhost, sshuser=${user.name}}
method=post|#]

[#|2010-12-23T09:01:37.451-0800|WARNING|glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=85;_ThreadName=admin-thread-pool-4848(2);|Cannot update node newSSH. It is in use by a server instance and therefore attribute installdir cannot be changed.|#]


and if i change to use keyFile, with force option, the error also disallows it:
"Warning: some parameters appear to be invalid. Key file /mydummykeyfile not found. The key file path must be reachable by the DAS. Continuing with node update due to use of --force. Cannot update node newSSH. It is in use by a server instance and therefore attribute installdir cannot be changed."

[#|2010-12-23T09:05:21.450-0800|FINEST|glassfish3.1|org.glassfish.admingui|_ThreadID=85;_ThreadName=admin-thread-pool-4848(2);ClassName=org.glassfish.admingui.common.util.RestUtil;MethodName=restRequest;|restRequest: endpoint=http://localhost:4848/management/domain/nodes/node/newSSH/update-node-ssh
attrs={sshkeyfile=/mydummykeyfile, sshpassword=null, installdir=${com.sun.aas.productRoot}

, nodedir=, force=true, sshport=22, nodehost=localhost, sshuser=${user.name}}
method=post|#]

[#|2010-12-23T09:05:21.468-0800|WARNING|glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=87;_ThreadName=admin-thread-pool-4848(4);|Cannot update node newSSH. It is in use by a server instance and therefore attribute installdir cannot be changed.|#]

The exact same steps succeed if there is no instance referring this node.

If you see anything wrong about what i pass in that causes you to prevent the user to update the ssh node when there is an instance ref it, let me know.
I believe GUI is passing in everything correct.

transfer back to Carla.

Comment by carlavmott [ 23/Dec/10 ]

I noticed in the log messages that the keyfile /mydummykeyfile is not found.

"Warning: some parameters appear to be invalid. Key file /mydummykeyfile not found. The key file path must be reachable by the DAS..."

At this point I don't know what to do as I can not reproduce this bug. I never see the message you have.

Comment by lidiam [ 23/Dec/10 ]

Tried the password to password alias scenario again on the latest nightly build, ogs-3.1-b34-12_23_2010.zip, and still see the problem. When attempting to switch from password to password file on a node that has a standalone instance I see the following error in Admin GUI:

An error has occurred
Cannot update node biffy. It is in use by a server instance and therefore attribute installdir cannot be changed.

The latest nightly build is installed both on DAS and the remote host, biffy. You may want to try on the latest nightly build instead of your workspace. Not sure if you can have a change there that's not present in the build.

Comment by carlavmott [ 27/Dec/10 ]

Using the nightly build from ms8

[#|2010-12-28T00:00:36.517-0008|INFO|glassfish3.1|null|_ThreadID=17;_ThreadName=Thread-1;|Running GlassFish Version: GlassFish Server Open Source Edition 3.1-SNAPSHOT (build 34)|#]

I can create an ssh node using the password option. create an instance referencing that node and then update the node to use the password alias option.

Closing bug because I can not reproduce.

Comment by lidiam [ 27/Dec/10 ]

I tried it again, on the latest nightly build, ogs-3.1-b35-12_27_2010.zip and the issue is still present. Anissa also sees the same issue, hence it may be good to ask others to try and reproduce it. I do not know why your installation of Glassfish behaves differently. I came by your office to show you exactly what I'm doing but you were already gone. Here are the steps:

1. Unzip ogs-3.1-b35-12_27_2010.zip on channi and start DAS.
2. Remove glassfish3 directory from biffy and vmbanta systems (tried on both just in case).
3. Execute asadmin install-node on channi and install Glassfish on biffy and vmbanta systems.
4. Go to Admin Console, click on Nodes and create an SSH node on biffy, specifying password for authentication.
5. Go to Standalone Instances and create an instance, in1, on biffy node.
6. Go to Domain -> Password Aliases tab and create a password alias that's valid for biffy machine.
7. Go to Edit Node screen for biffy and select Password Alias in SSH User Authentication, click Save. The action fails and the same error is displayed, that installdir cannot be changed.

Tried also this:

8. Go to Nodes and create another SSH node on vmbanta, with key file.
9. Create a standalone instance under vmbanta.
10. Go to Edit Node screen for vmbanta and replace SSH User Name with the actual user name (instead of token), hit Save. Again the same error is displayed saying that attribute installdir cannot be changed. Here is the error from server.log:

[#|2010-12-27T16:58:40.075-0800|WARNING|oracle-glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=19;_ThreadName=Thread-1;|Cannot update node vmb. It is in use by a server instance and therefore attribute installdir cannot be changed.|#]

Glassfish version:
channi(j2eetest):/export/home/j2eetest/v31# asadmin version
Version = Oracle GlassFish Server 3.1 (build 35)
Command version executed successfully.

[#|2010-12-27T16:50:07.972-0800|INFO|oracle-glassfish3.1|null|_ThreadID=19;_ThreadName=Thread-1;|Running GlassFish Version: Oracle GlassFish Server 3.1 (build 35)|#]

This issue needs further investigation.

Comment by Joe Di Pol [ 28/Dec/10 ]

I can reproduce this – you must leave the installdir the default value of "$

{com.sun.aas.productRoot}". This must have something to do with the fact that the command is comparing the expanded value of the variable with the string "${com.sun.aas.productRoot}

" and deciding they are different.

I'll take this bug since I last touched this part of the code.

Comment by Joe Di Pol [ 28/Dec/10 ]

How bad is its impact? (Severity)

Under some situations users of the admin console will not be able to update node information, such as the nodehost. And to make it worse, when this condition occurs they are informed that they can't change the installdir – even though they are not.

How often does it happen? Will many users see this problem? (Frequency)

Any user that tries to update an SSH node using the console with the default installdir setting (

{com.sun.aas.productRoot}

). So it could be fairly common.

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

Low effort. This is basically a continuation of the fix for 15245 which missed a case. Most effort will go into testing.

What is the risk of fixing it and how will the risk be mitigated? (Risk)

Fairly low risk. I will verify it fixes the bug and then run quicklook and the admin cli dev tests.

Note that the fix for this issue also fixes:
http://java.net/jira/browse/GLASSFISH-15309

Comment by Nazrul [ 28/Dec/10 ]

Approved for checkin

Comment by Joe Di Pol [ 29/Dec/10 ]

Project: glassfish
Repository: svn
Revision: 44153
Author: jfdipol
Date: 2010-12-29 21:59:50 UTC
Link:

Log Message:
------------
15291 Cannot modify SSH node with instances when installdir is not changed
15309 User is not allowed to modify install/node dir but can clear it

Code Review: Carla Mott
Approver: Nazrul

Comment by lidiam [ 30/Jan/11 ]

verified on promoted build b39





[GLASSFISH-15290] IllegalStateException from jts initRecovery during gf 3.1 startup running nile bookstore app Created: 21/Dec/10  Updated: 21/Dec/10  Resolved: 21/Dec/10

Status: Closed
Project: glassfish
Component/s: jts
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_ms08

Type: Bug Priority: Major
Reporter: Joe Fialli Assignee: marina vatkina
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

build 33

Deployed niles bookstore on a 3-node cluster.
Using Oracle Load Testing Harness ran longevity test.

[#|2010-12-10T00:22:34.875-0800|WARNING|oracle-glassfish3.1|javax.enterprise.system.core.transaction.com.sun.jts.jta|_ThreadID=16;_ThreadName=Thread-1;|
java.lang.IllegalStateException
at com.sun.jts.jta.TransactionServiceProperties.initRecovery(TransactionServiceProperties.java:283)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.initRecovery(JavaEETransactionManagerJTSDelegate.java:408)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.initRecovery(JavaEETransactionManagerSimplified.java:287)
at com.sun.enterprise.transaction.startup.TransactionRecoveryWrapper.onReady(TransactionRecoveryWrapper.java:100)
at com.sun.enterprise.transaction.startup.TransactionRecoveryWrapper$1.event(TransactionRecoveryWrapper.java:86)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:321)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
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.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]

log:
http://aras2.us.oracle.com:8080/logs/gf31/gms/set_12_19_10_t_22_43_52/scenario_0001_Sun_Dec_19_22_44_16_PST_2010/n1c1m3/logs/server.log

all logs:
http://aras2.us.oracle.com:8080/logs/gf31/gms/set_12_19_10_t_22_43_52/scenario_0001_Sun_Dec_19_22_44_16_PST_2010/



 Comments   
Comment by marina vatkina [ 21/Dec/10 ]

Duplicate of http://java.net/jira/browse/GLASSFISH-15164 that was fixed after b33





[GLASSFISH-15284] Registration landing html page fixes Created: 20/Dec/10  Updated: 23/Dec/10  Resolved: 23/Dec/10

Status: Resolved
Project: glassfish
Component/s: other
Affects Version/s: 3.1_ms07
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

1) Use the new production URL for registration, replacing the test URL.
2) Make landing page localizable.
3) Fix product name



 Comments   
Comment by sirajg [ 21/Dec/10 ]

1. How bad is its impact? (Severity)
High
2. How often does it happen? (Frequency)
Anyone who uses the installer
3. How much effort is required to fix it? (Cost)
1 day
4. What is the risk of fixing it? (Risk)
Low

Comment by sirajg [ 23/Dec/10 ]

Fixed in revision 44066





[GLASSFISH-15273] create-file-user and list-file-user doesn't sync up. Created: 19/Dec/10  Updated: 24/Dec/10  Resolved: 24/Dec/10

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_ms08

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

Tags: 3_1-approved

 Description   

server-config admin-realm and default-config admin-realm has the same keyFile property, so, when adding user targeting to one config will show up as user in the other config as well. I understand this part.

However, there are issues with the user list. I don't know if its a create-user bug, or list-user bug.
I am using the latest nightly (12/19) build.

Here is what i did:

~ 14) v3admin list-file-users --authrealmname admin-realm server-config
admin
Command list-file-users executed successfully.

~ 15) v3admin list-file-users --authrealmname admin-realm default-config
admin
Command list-file-users executed successfully.
~ 16)

so far so good. now, start creating user.

~ 16) v3admin create-file-user --authrealmname admin-realm --target default-config admin2
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
~ 17)
~ 17)
~ 17) v3admin list-file-users --authrealmname admin-realm default-config
admin
admin2
Command list-file-users executed successfully.

'admin2' should be reflected in server-config also, since they have the same keyFile. But thats not what i saw.

~ 18) v3admin list-file-users --authrealmname admin-realm server-config
admin <============ BUG. It should also list admin2
Command list-file-users executed successfully.
~ 19)

Now, add another user to server-config

~ 19) v3admin create-file-user --authrealmname admin-realm --target server-config admin3
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
~ 20)

Now, all of a sudden, admin2 starts showing up.

~ 20) v3admin list-file-users --authrealmname admin-realm server-config
admin
admin3
admin2
Command list-file-users executed successfully.

but then, default-config doesn't show admin3.

~ 21) v3admin list-file-users --authrealmname admin-realm default-config
admin
admin2 <==== ??? where is admin3
Command list-file-users executed successfully.

Now, add another user to 'default-config', admin3 still doesn't show up.

~ 24) v3admin create-file-user --authrealmname admin-realm --target default-config admin4
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
~ 25) v3admin list-file-users --authrealmname admin-realm default-config
admin
admin4
admin2
Command list-file-users executed successfully.
=================

Now, this is even surprising. copy the config, but they don't show the same user.

~ 26)
~ 26) v3admin copy-config server-config new-config
Command copy-config executed successfully.
~27)
~ 27) v3admin list-file-users --authrealmname admin-realm new-config
admin
admin4
admin2
Command list-file-users executed successfully.
~ 28) v3admin list-file-users --authrealmname admin-realm server-config
admin
admin3
admin2
Command list-file-users executed successfully.

I have no idea what is going on, when the user will show up, etc . Because of this bug, GUI screen showing file user is not usable at all.



 Comments   
Comment by kumarjayanti [ 19/Dec/10 ]

How bad is its impact? (Severity)
Severe. Without this fix list-file-users when applied to different configs with shared realm-keyfile shows different random behavior

How often does it happen? Will many users see this problem? (Frequency)
The problem only happens if the key-file of a realm is shared across different configs.

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

What is the risk of fixing it and how will the risk be mitigated? (Risk)
None

Fix : a refresh call needs to be added to list-file-users to account for a shared key-file usecase.

Comment by kumarjayanti [ 20/Dec/10 ]

Tested the above sequence after the fix :

V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin list-file-users --authrealmname admin-realm default-config
admin
Command list-file-users executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin list-file-users --authrealmname admin-realm server-config
admin
Command list-file-users executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin create-file-user --authrealmname admin-realm --target default-config admin2
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin list-file-users --authrealmname admin-realm default-config
admin
admin2
Command list-file-users executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin list-file-users --authrealmname admin-realm server-config
admin
admin2
Command list-file-users executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin create-file-user --authrealmname admin-realm --target server-config admin3
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin list-file-users --authrealmname admin-realm server-config
admin
admin3
admin2
Command list-file-users executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin list-file-users --authrealmname admin-realm default-config
admin
admin3
admin2
Command list-file-users executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin create-file-user --authrealmname admin-realm --target default-config admin4
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin list-file-users --authrealmname admin-realm default-config
admin
admin4
admin3
admin2
Command list-file-users executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin copy-config server-config new-config
Command copy-config executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin list-file-users --authrealmname admin-realm new-config
admin
admin4
admin3
admin2
Command list-file-users executed successfully.
V-B-Kumar-Jayantis-MacBook-Pro:bin vbkumarjayanti$ ./asadmin list-file-users --authrealmname admin-realm server-config
admin
admin4
admin3
admin2
Command list-file-users executed successfully.

Comment by kumarjayanti [ 20/Dec/10 ]

svn diff of the fix :
--------------

V-B-Kumar-Jayantis-MacBook-Pro:core vbkumarjayanti$ svn diff
Index: src/main/java/com/sun/enterprise/security/auth/realm/file/FileRealm.java
===================================================================
— src/main/java/com/sun/enterprise/security/auth/realm/file/FileRealm.java (revision 43663)
+++ src/main/java/com/sun/enterprise/security/auth/realm/file/FileRealm.java (working copy)
@@ -372,6 +372,37 @@

/**
+ * Refreshes the realm data so that new users/groups are visible.
+ *
+ * <P>A new FileRealm instance is created and initialized from the
+ * keyfile on disk. The new instance is installed in the Realm registry
+ * so future Realm.getInstance() calls will obtain the new data. Any
+ * existing references to this instance (e.g. in active LoginModule
+ * sessions) are unaffected.
+ * @param config
+ * @exception BadRealmException if realm data structures are bad
+ *
+ */
+ @Override
+ public void refresh(String configName)
+ throws BadRealmException
+ {
+ if (_logger.isLoggable(Level.FINE))

{ + _logger.fine("Reloading file realm data."); + }

+
+ FileRealm newRealm = new FileRealm();
+
+ try

{ + newRealm.init(getProperties()); + Realm.updateInstance(configName, newRealm, this.getName()); + }

catch (Exception e)

{ + throw new BadRealmException(e.toString()); + }

+ }
+
+
+ /**

  • Authenticates a user.
    *
  • <P>This method is invoked by the FileLoginModule in order to
    Index: src/main/java/com/sun/enterprise/security/auth/realm/Realm.java
    ===================================================================
      • src/main/java/com/sun/enterprise/security/auth/realm/Realm.java (revision 43663)
        +++ src/main/java/com/sun/enterprise/security/auth/realm/Realm.java (working copy)
        @@ -386,6 +386,37 @@
        _logger.log(Level.INFO, "realm.updated.successfully",new Object[] {realm.getName()});
        }

        + /**
        + * Replace a Realm instance. Can be used by a Realm subclass to
        + * replace a previously initialized instance of itself. Future
        + * getInstance requests will then obtain the new instance.
        + *
        + * <P>Minimal error checking is done. The realm being replaced must
        + * already exist (instantiate() was previously called), the new
        + * instance must be fully initialized properly and it must of course
        + * be of the same class as the previous instance.
        + *
        + * @param realm The new realm instance.
        + * @param name The (previously instantiated) name for this realm.
        + *
        + */
        + protected static synchronized void updateInstance(String configName, Realm realm, String name)
        + {
        + RealmsManager mgr = getRealmsManager();
        + if (mgr == null) { + throw new RuntimeException("Unable to locate RealmsManager Service"); + }
        +
        + Realm oldRealm = mgr.getFromLoadedRealms(configName, name);
        + if (!oldRealm.getClass().equals(realm.getClass())) { + // would never happen unless bug in realm subclass + throw new Error("Incompatible class "+realm.getClass()+ + " in replacement realm "+name); + }
        + realm.setName(oldRealm.getName());
        + mgr.putIntoLoadedRealms(configName, name, realm);
        + _logger.log(Level.INFO, "realm.updated.successfully",new Object[]{realm.getName()}

        );
        + }

/**

  • Convenience method which returns the Realm object representing
    @@ -803,6 +834,15 @@
  • @exception BadRealmException if realm data structures are bad
    */
    public abstract void refresh() throws BadRealmException;
    +
    + /**
    + * Refreshes the realm data so that new users/groups are visible.
    + *
    + * @exception BadRealmException if realm data structures are bad
    + */
    + public void refresh(String configName) throws BadRealmException { + //do nothing + }

/**

  • Adds new user to file realm. User cannot exist already.

Index: src/main/java/com/sun/enterprise/security/cli/CreateFileUser.java
===================================================================
— src/main/java/com/sun/enterprise/security/cli/CreateFileUser.java (revision 43663)
+++ src/main/java/com/sun/enterprise/security/cli/CreateFileUser.java (working copy)
@@ -260,7 +260,7 @@
fr.writeKeyFile(kf);
}
//Since this is done prior to adding the user, it is redundant here.

  • //refreshRealm(authRealmName);
    + //refreshRealm(authRealmName);
    report.setActionExitCode(ActionReport.ExitCode.SUCCESS);
    } catch (Exception e) {
    String localalizedErrorMsg = (e.getLocalizedMessage() == null)?"":e.getLocalizedMessage();
    @@ -323,7 +323,7 @@
    Realm realm = Realm.getInstance(configName, realmName);

if(realm != null)

{ - realm.refresh(); + realm.refresh(configName); }

}catch(com.sun.enterprise.security.auth.realm.NoSuchRealmException nre){
// _logger.fine("Realm: "realmName" is not configured");
Index: src/main/java/com/sun/enterprise/security/cli/ListFileUser.java
===================================================================
— src/main/java/com/sun/enterprise/security/cli/ListFileUser.java (revision 43663)
+++ src/main/java/com/sun/enterprise/security/cli/ListFileUser.java (working copy)
@@ -202,6 +202,9 @@
FileRealm fr = null;
try {
realmsManager.createRealms(config);
+ //account for updates to realms from outside this config sharing
+ //same keyfile
+ CreateFileUser.refreshRealm(config.getName(),authRealmName);
fr = (FileRealm) realmsManager.getFromLoadedRealms(config.getName(),authRealmName);
if (fr == null)

{ throw new NoSuchRealmException(authRealmName); @@ -217,7 +220,7 @@ return; }
  • try {
    + try {
    Enumeration users = fr.getUserNames();
    List userList = new ArrayList();
Comment by Nazrul [ 20/Dec/10 ]

Approved for checkin

Comment by Nithya Ramakrishnan [ 24/Dec/10 ]

Committed revision 44084





[GLASSFISH-15262] Win 2008. create-node-ssh, then create-instance, got NPE. Created: 17/Dec/10  Updated: 28/Dec/10  Resolved: 28/Dec/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 3.1_ms08

Type: Bug Priority: Major
Reporter: easarina 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

 Description   

Windows 2008. Installed glassfish b34 on two machines. ssh without config was configured. Was used b34.

A lot of remote commands were executed successfully.

create-node-ssh was executed succesfully:

C:\hudson\workspace\Cluster\glassfish3\glassfish\bin>asadmin create-node-ssh --n
odehost jed-asqe-21 --installdir C:\hudson\workspace\Cluster\glassfish3 --nodedir C:\hudson\workspace\Cluster\glassfish3\glassfish\nodes temp
Command create-node-ssh executed successfully.

Then I tried to create an instance for that node, but got NPE:

C:\hudson\workspace\Cluster\glassfish3\glassfish\bin>asadmin create-instance --node temp i1
Successfully created instance i1 in the DAS configuration, but failed to install
configuration files for the instance on node jed-asqe-21 during bootstrap.

SSH configuration information

Additional failure info: java.lang.NullPointerException.
Command create-instance executed successfully.

In server.log were seen such messages:
==================================================
[#|2010-12-17T17:06:08.872-0800|INFO|glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=17;_ThreadName=Thread-1;|Command _create-instance-filesystem executed successfully.|#]

[#|2010-12-17T17:06:09.842-0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=17;_ThreadName=Thread-1;|Successfully created instance i1 in the DAS configuration, but failed to install configuration files for the instance on node jed-asqe-21 during bootstrap.

SSH configuration information

Additional failure info: java.lang.NullPointerException.|#]
======================================================================

Then I've started this instance, looks like the instance was started:

C:\hudson\workspace\Cluster\glassfish3\glassfish\bin>asadmin start-instance i1
Attempting to start i1.... Please look at the server log for more details.....
The instance, i1, was started on host jed-asqe-21
Command start-instance executed successfully.

C:\hudson\workspace\Cluster\glassfish3\glassfish\bin>asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
i1 jed-asqe-21 24848 3428 — running
Command list-instances executed successfully.

C:\hudson\workspace\Cluster\glassfish3\glassfish\bin>

On other platforms it works fine.



 Comments   
Comment by carlavmott [ 21/Dec/10 ]

We support MKS only or cygwin only installations and not a mixture of the two.

Comment by easarina [ 21/Dec/10 ]

I've got the same problem on other machines. And all tests passed except this one. Please see:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/Cluster/59/artifact/appserver-sqe/reports/pe-pe/amd64_ASQE-OBLADE-14_Windows_NT/test_results.html

The failed test: "Create two instances with default ports, verify that ports numbers were published at the window fail"

Comment by easarina [ 21/Dec/10 ]

This is a windows bug, all other tests - passed.

Comment by carlavmott [ 22/Dec/10 ]

Does this happen on all windows systems?

Comment by carlavmott [ 22/Dec/10 ]

I don't have windows machines to test on and am still looking

Comment by easarina [ 22/Dec/10 ]

I have other pure cygwin Win 2008 machines. On these machines I saw the same issue:

C:\export\glassfish3\glassfish\bin>asadmin create-instance --node temp i2
Successfully created instance i2 in the DAS configuration, but failed to install
configuration files for the instance on node bigapp-oblade-2 during bootstrap.

SSH configuration information

Additional failure info: java.lang.NullPointerException.
Command create-instance executed successfully.

Comment by Yamini K B [ 22/Dec/10 ]

Works for me on my cygwin setup:

$ ./asadmin create-instance --node n1 ins1
Command _create-instance-filesystem executed successfully.
Port Assignments for server instance ins1:
JMX_SYSTEM_CONNECTOR_PORT=28686
JMS_PROVIDER_PORT=27676
HTTP_LISTENER_PORT=28080
ASADMIN_LISTENER_PORT=24848
JAVA_DEBUGGER_PORT=29009
IIOP_SSL_LISTENER_PORT=23820
IIOP_LISTENER_PORT=23700
OSGI_SHELL_TELNET_PORT=26666
HTTP_SSL_LISTENER_PORT=28181
IIOP_SSL_MUTUALAUTH_PORT=23920
The instance, ins1, was created on host underpass.india.sun.com
Command create-instance executed successfully.

Yamini@ducati ~/gf/glassfish3/glassfish/bin
$

I tried with both password authentication and public key auth.

In your case, need to see why it failed to copy the config files. Can you please increase admin logging level to finest and send across the server log?

Comment by Yamini K B [ 22/Dec/10 ]

Tim, the NPE seems to be coming from secure admin bootstrap, can you please take a look?

Comment by Tim Quinn [ 22/Dec/10 ]

I had already started investigating this.

The problem occurs when the bootstrapping code tries to create directories on the target system over the ssh connection.

Still working on it...

Comment by Tim Quinn [ 23/Dec/10 ]

There is an error in SecureAdminBootstrapHelper.

But when I fixed it, the code still could not copy the files over to the target system during bootstrapping.

I think the new problem is that the cygwin ssh was set-up on the target system to use a directory other than the root for the default path. The bootstrapping process basically uses callable sftp to copy files from the DAS to the instance. Bootstrapping uses the node directory information the user provided, but it seems that ssh on the target system qualifies all file paths by looking for them inside the configured default cygwin directory.

Commands which the DAS submits over ssh to be run on the remote instance use the same node directory path, but because that value is passed essentially as a string and is interpreted in a command shell on the remote system, that path is not qualifed by the default cygwin directory.

If this what's happening, then for 3.1 we might need to have users set the ssh initial path to the root ("\") directory. Otherwise the node directory which submitted ssh commands refer to and the node directory which bootstrapping tries to find will never match up.

Comment by Tim Quinn [ 23/Dec/10 ]

Requesting approval for fixing a problem in SecureAdminBootstrapHelper.

For remote insta