[GLASSFISH-16215] debug message missing when debugging server startup Created: 15/Mar/11  Updated: 20/Dec/16  Resolved: 19/Apr/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 3.1.1, 4.0_dev

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

Tags: 3_1-next

 Description   

Am trying to attach debugger during GF startup, so I have suspend=y in domain.xml. When starting with "asadmin start-domain --debug," there used to be a message sent to console telling me that the server was waiting for someone to attach on the debugging port. This message is now missing. Instead, I only see:

— begin —
hostname% ./asadmin start-domain --debug
Waiting for domain1 to start ......
— end —

The message eventually appears, but it's not until startup has completed (after I've finished my debug session):

— begin —
hostname% ./asadmin start-domain --debug
Waiting for domain1 to start ................................................................
Successfully started the domain : domain1
domain Location: /Users/bobby/work/ws/v3/distributions/glassfish/target/glassfish3/glassfish/domains/domain1
Log File: /Users/bobby/work/ws/v3/distributions/glassfish/target/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Debugging is enabled. The debugging port is: 9009
Command start-domain executed successfully.
— end —

Without this message, it could confuse anyone trying to debug as it appears now that the server just isn't responsive.



 Comments   
Comment by Byron Nevins [ 15/Mar/11 ]

This started happening after the "early logging" changes.

Comment by Byron Nevins [ 15/Mar/11 ]

It's even worse. It only emits a message when you give "--debug" arg.
If debug-enabled is set in domain.xml then nothing is reported!

Comment by Byron Nevins [ 15/Mar/11 ]

2 changes:

(1) if debugging is enabled in domain.xml and/or the --debug option was used then a message is emitted

(2) Now we check for suspended. If it is set then an early message is emitted:

D:\gf\v3\admin\cli>call asadmin start-domain
Debugging is enabled and the server is suspended. Please attach to the debugging port at: 9009
Successfully started the domain : domain1
domain Location: D:\glassfish3\glassfish\domains\domain1
Log File: D:\glassfish3\glassfish\domains\domain1\logs\server.log
Admin Port: 4848
Debugging is enabled. The debugging port is: 9009

Comment by Byron Nevins [ 15/Mar/11 ]

D:\gf\v3\admin>svn commit
Sending admin\cli\src\main\java\com\sun\enterprise\admin\cli\LocalStrings.properties
Sending admin\cli\src\main\java\com\sun\enterprise\admin\cli\StartServerHelper.java
Sending admin\launcher\src\main\java\com\sun\enterprise\admin\launcher\GFLauncher.java
Transmitting file data ...
Committed revision 45573.

Done. Thanks for finding this, Bobby...

Comment by Bobby Bissett [ 16/Mar/11 ]

Looks good. Thanks for the quick fix!

Comment by Byron Nevins [ 19/Apr/11 ]

it won't let me edit so I'm reopening. Weird.

Comment by Byron Nevins [ 19/Apr/11 ]

.





[GLASSFISH-16727] typos in asadmin CLI --help pages Created: 24/May/11  Updated: 20/Dec/16  Resolved: 30/Jun/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_dev
Fix Version/s: 3.1.1

Type: Bug Priority: Trivial
Reporter: Dies Koper Assignee: Paul Davies
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

asadmin --help:

DatabaseName="jdbc:derby":server="http://locahost:9092"'
->
DatabaseName="jdbc:derby":server="http://localhost:9092"'

asadmin create-domain --help:

ferent hots (where the home directory is NFS mounted),
->
ferent hosts (where the home directory is NFS mounted),

o JPA debugger port: portbase + 9
->
o JPDA debugger port: portbase + 9



 Comments   
Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in 3.1.1

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.





[GLASSFISH-16918] EJBs leak between deploy / undeploy cycles Created: 27/Jun/11  Updated: 20/Dec/16  Resolved: 01/Jul/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 4.0_dev
Fix Version/s: 3.1.1

Type: Bug Priority: Major
Reporter: Aslak Knutsen Assignee: Bhavanishankar
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 11.04, OpenJDK 1.6


Attachments: File 30cec0f9-8147-4784-9625-f8903f97b3ce.war     File c0c413d7-c1be-41c6-9624-383ab2ee636a.ear     File ejb-ejb30-hello-session3-web.war     File ejb-ejb30-hello-session3App.ear     Java Source File UndeployIssueTestCase.java    

 Description   

Steps to reproduce:

1. deploy a war with a single EJB
2. undeploy war
3. deploy a ear with two modules, one EJB module that has the same EJB as in step 1 and a WAR that has a client that use @EJB injection of the same EJB.

The 3. step fails with:

java.lang.IllegalArgumentException: Cannot resolve reference Remote ejb-ref name=org.jboss.arquillian.container.glassfish.embedded_3_1.app.UndeployIssueTestCase$MyClient/ejb,Remote 3.x interface =org.jboss.arquillian.container.glassfish.embedded_3_1.app.UndeployIssueTestCase$MyEJB,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session because there are 2 ejbs in the application with interface org.jboss.arquillian.container.glassfish.embedded_3_1.app.UndeployIssueTestCase$MyEJB. 
Some of the possible causes: 
1. The EJB bean class was packaged in an ear lib library (or through any other library mechanism which makes the library visible to all component modules), this makes all the component modules include this bean class indirectly. 
2. The EJB bean class was packaged in a component module which references the EJB, either directly or indirectly through Manifest, WEB-INF/lib. 
The EJB bean class should only be packaged in the declaring ejb module and not the referencing modules. The referencing modules should only include EJB interfaces.
	at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:590)
	at com.sun.enterprise.deployment.WebBundleDescriptor.visit(WebBundleDescriptor.java:2003)
	at com.sun.enterprise.deployment.Application.visit(Application.java:1777)
	at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:811)
	at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:277)
	at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240)
	at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:173)
	at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:828)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:770)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:388)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:360)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1069)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:98)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1249)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1237)
	at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.executeCommand(CommandExecutorImpl.java:147)
	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:99)
	at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:89)
	at 

Deploying the EAR alone works just fine.



 Comments   
Comment by marina vatkina [ 27/Jun/11 ]

This works fine in non-embedded GF. So EJB container work correctly when everything else works correctly. Assigning to Bhavani to check the embedded deployment part.

Comment by Bhavanishankar [ 28/Jun/11 ]

Please upload both the EJB jar and EAR used for running this case.

Comment by Aslak Knutsen [ 28/Jun/11 ]

Both deployments are Generated as part of the uploaded testcase.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.glassfish</groupId>
    <artifactId>glassfish_16918</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>GLASSFISH-16918</name>
    <repositories>
        <repository>
            <id>jboss-public-repository-group</id>
            <name>JBoss Public Repository Group</name>
            <url>http://repository.jboss.org/nexus/content/groups/public/</url>
            <layout>default</layout>
            <releases>
                <enabled>true</enabled>
                <updatePolicy>never</updatePolicy>
            </releases>
            <snapshots>
                <enabled>true</enabled>
                <updatePolicy>never</updatePolicy>
            </snapshots>
        </repository>
    </repositories>
    <dependencies>
        <dependency>
            <groupId>org.glassfish.extras</groupId>
            <artifactId>glassfish-embedded-all</artifactId>
            <version>3.2-b06</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.shrinkwrap</groupId>
            <artifactId>shrinkwrap-impl-base</artifactId>
            <version>1.0.0-beta-3</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.8.1</version>
        </dependency>
    </dependencies>
</project>
Comment by Aslak Knutsen [ 28/Jun/11 ]

as you wish...

Comment by marina vatkina [ 30/Jun/11 ]

ear and war file that I used

Comment by Bhavanishankar [ 01/Jul/11 ]

I think it is a bug specific only to the build you are using.

With 3.1.1-SNAPSHOT everything works fine.

Please change your pom to refer to org.glassfish.extras:glassfish-embedded-all:3.1.1-SNAPSHOT





[GLASSFISH-16663] Rotate cluster log rewrites url and subsequent Launch application link brings 404 error. Created: 16/May/11  Updated: 20/Dec/16  Resolved: 15/Nov/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1_dev, 3.1.1, 4.0_dev, 4.0

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

Glassfish server 3.1.1 b4 on AIX 6.1, browser: Firefox 3.6.15 on WindowsXP.


Attachments: JPEG File 404launch-error.JPG     JPEG File 404launch-url.JPG     File hello.war    
Tags: 3_1_1-approved, 3_1_1-scrubbed, 3_1_1-verified

 Description   

It took a while to find the cause of this issue: after clicking Launch link on Edit Application screen, a 404 error is displayed instead of a list of links to the deployed application. This only happens when user clicks on Rotate Log button for a cluster, prior to clicking the Launch link.

Admin Console url gets rewritten after rotating cluster log and stays as http://<DAS host>:<port>/cluster/cluster/clusterGeneral.jsf?clusterName=<cluster name>. This is similar to the url that is displayed when 404 error is encountered. Hence the steps to reproduce this issue are:

1. Create a standalone instance and start it.
2. Create a cluster with one instance and start it.
3. Go to cluster General Information page and click Rotate Log button, click OK.
4. Go to Applications, New page and deploy an app to the standalone instance, e.g. hello.war.
5. Click on application name to get to Edit Application page and click on Launch link: 404 error will be displayed in new browser window.

While the url seems wrong for Launch link on Applications page, it works fine in the above condition. Only the Launch link on Edit Application page brings 404 error.



 Comments   
Comment by lidiam [ 17/May/11 ]

This issue is not specific to AIX. I reproduced it in the following environment:

  • Glassfish 3.1 b43 running on Solaris
  • Firefox browser on WindowsXP
Comment by sirajg [ 18/May/11 ]

Why fix this issue in 3.1.1?
o Poor user experience

Which is the targeted build of 3.1.1 for this fix?
o MS4

Do regression tests exist for this issue?
o No. Manual testing should be sufficient

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
o verify the bug reported is fixed

Diffs :

— src/main/resources/applications/subComponentTable.inc (revision 46292)
+++ src/main/resources/applications/subComponentTable.inc (working copy)
@@ -77,7 +77,7 @@
url="#

{request.contextPath}/common/applications/endpoint.jsf?appName=#{appName}&moduleName=#{td.value.moduleName}&compName=#{td.value.name}" />

<sun:hyperlink id="link" rendered="#{td.value.hasLaunch}" text="$resource{i18n.deployTable.launch}"
- onClick="var win=window.open('applications/webApplicationLinks.jsf?appID=#{appName}&contextRoot=#{td.value.contextRoot}','ViewerWindow','width='.75*screen.width',height='.75*screen.height',top='.1*screen.height',left='.1*screen.width',toolbar=yes,status=yes,menubar=yes,scrollbars=yes,resizable=yes,directories=yes,location=yes');win.focus(); return false;" />
+ onClick="var win=window.open('#{request.contextPath}

/common/applications/webApplicationLinks.jsf?appID=#

{appName}&contextRoot=#{td.value.contextRoot}','ViewerWindow','width='.75*screen.width',height='.75*screen.height',top='.1*screen.height',left='.1*screen.width',toolbar=yes,status=yes,menubar=yes,scrollbars=yes,resizable=yes,directories=yes,location=yes');win.focus(); return false;" />

<sun:hyperlink id="appClientLink" rendered="#{td.value.hasAppClientLaunch}" text="$resource{i18n.deployTable.launch}"
url="#{request.contextPath}/common/applications/appclientLaunch.jsf?appName=#{appName}

&moduleName=#

{td.value.moduleName}

"/>

Comment by Anissa Lam [ 18/May/11 ]

Please check into both trunk and 3.1.1. branch.

Comment by sirajg [ 18/May/11 ]

revision 46926/trunk
revision 46924/ 3.1.1

Comment by lidiam [ 24/Jun/11 ]

Verified in build b08. While the url is still re-written on cluster log rotation, Launch link from Edit Application page works fine afterward.

Comment by Anissa Lam [ 17/Oct/11 ]

reopen issue to mark the fix version of 3.1.1

Comment by Anissa Lam [ 15/Nov/11 ]

Change Resolution back to Fixed.





[GLASSFISH-10568] ql: failed to deploy jsfastrologer.war on AIX. Created: 25/Oct/09  Updated: 20/Dec/16  Resolved: 07/Oct/10

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1_dev
Fix Version/s: 3.1.1

Type: Bug Priority: Blocker
Reporter: sherryshen Assignee: kchung
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: AIX
Platform: All


Attachments: Text File server.log.jsfastrologer    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16364 OSGI issue shown by Bean validator on... Resolved
Issuezilla Id: 10,568
Status Whiteboard:

v3_exclude

Tags: 3_1_1-approved

 Description   

With the fix of
https://glassfish.dev.java.net/issues/show_bug.cgi?id=10545
it is OK to deploy hellojsp.war, but next failure is at
deploying jsfastrologer.war

The ql run is w.r.t. gf-trunk-build-continuous,
around #2995, Oct. 25, 2009. The build has the fix
33289. Issue #10545: Add org.glassfish.apf.context to Import-Package
explicitly to solve class loading issue on IBM JDK

The hudson run can be viewed at
http://sqe-hudson.sfbay.sun.com:8080/hudson/job/sherry-ql-aix/3/

deploy-v3-impl:
[echo] deploying hellojsp.war
deploy-v3-impl-unix:
[exec] Application deployed successfully with name hellojsp.war
.....
[exec] Command deploy executed successfully.
deploy-v3-impl:
[echo]
deploy-v3-impl-unix:
[exec] com.sun.enterprise.admin.cli.CommandException:
remote failure: Exception while loading the app :
java.lang.Exception: java.lang.IllegalStateException:
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException:
org.apache.catalina.LifecycleException:
java.lang.IllegalStateException:
Application was not properly initialized at startup,
could not find Factory:
javax.faces.context.FacesContextFactory
[exec] Command deploy failed.
[exec] Result: 1
....
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 110, Failures: 73, Skips: 29
[echo] [testng] Configuration Failures: 1, Skips: 0
[echo] [testng] ===============================================



 Comments   
Comment by sherryshen [ 25/Oct/09 ]

added line for war file, which was mis-copied before.

deploy-v3-impl:
[echo] deploying jsfastrologer.war
deploy-v3-impl-unix:
[exec] com.sun.enterprise.admin.cli.CommandException:
remote failure: Exception while loading the app :
java.lang.Exception: java.lang.IllegalStateException:
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException:
org.apache.catalina.LifecycleException:
java.lang.IllegalStateException:
Application was not properly initialized at startup,
could not find Factory:
javax.faces.context.FacesContextFactory
[exec] Command deploy failed.
[exec] Result: 1

Comment by Sanjeeb Sahoo [ 26/Oct/09 ]

Next time, attach server.log.
Reassigning to jsf team to do initial investigation.

Comment by Sanjeeb Sahoo [ 26/Oct/09 ]

added cc

Comment by Ryan Lubke [ 26/Oct/09 ]

Please attach the server log for the failed run.

Thanks.

Comment by sherryshen [ 26/Oct/09 ]

Created an attachment (id=3624)
server.log for deploying jsfastrologer.war

Comment by sherryshen [ 26/Oct/09 ]

The steps and env to get server.log.jsfastrologer.
-bash-3.00$ ./asadmin start-domain
Waiting for DAS to start ................
Started domain: domain1
Domain location:
/export/hudson/workspace/sherry-ql-aix/glassfishv3/glassfish/domains/domain1
Log file:
/export/hudson/workspace/sherry-ql-aix/glassfishv3/glassfish/domains/domain1/logs/server.log
Admin port for the domain: 4848
Command start-domain executed successfully.
-bash-3.00$ asadmin deploy
/export/hudson/workspace/sherry-ql-aix/quicklook/dist/jsftest/jsfastrologer.war
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while
loading the app : java.lang.Exception: java.lang.IllegalStateException:
ContainerBase.addChild: start: org.apache.catalina.LifecycleException:
org.apache.catalina.LifecycleException: java.lang.IllegalStateException:
Application was not properly initialized at startup, could not find Factory:
javax.faces.context.FacesContextFactory
Command deploy failed.
-bash-3.00$-bash-3.00$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap3260sr5-20090529_04(SR5))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 AIX ppc-32
jvmap3260sr5-20090519_35743 (JIT enabled, AOT enabled)
J9VM - 20090519_035743_bHdSMr
JIT - r9_20090518_2017
GC - 20090417_AA)
JCL - 20090529_01
-bash-3.00$

Comment by Ryan Lubke [ 26/Oct/09 ]

JSF is not being initialized (no log message indicating it's being bootstrapped)
when the application is deployed. This means that our ServletContextListener
isn't being invoked by the web container.

To confirm, what build of v3 is this?

Comment by Ryan Lubke [ 26/Oct/09 ]

I'm able to reproduce the issue on aixas13.sfbay.sun.com using the web bundle
from the GF continuous build [1].

I put some break points within the web container where the container invokes the
integration points JSF uses with the web container (mainly the
ServletContextListener and ServletContainerInitializer). In both cases, there
were no ServletContextListeners or ServletContainerInitializers present. This
meshes with my observation of the log - no jsf initialization message.

Jan, can you please look into this?

[1] http://hudson.glassfish.org/job/gf-trunk-build-continuous/

Comment by kumara [ 26/Oct/09 ]

AIX support is being defered to v3.1. Thank you everyone for your hard work in getting AIX support so far
along in v3 release.

Comment by sherryshen [ 29/Oct/09 ]

Not a blocker any more.

Comment by Shing Wai Chan [ 30/Oct/09 ]

In the debugger, I saw that
ServletContainerInitializerUtil.getServletContainerInitializers() return an
empty Iterable in that environment.

In a ubunta machine, if I switch to use IBM JDK, then I see the same problem.
So, this is an IBM JDK related issue, rather than AIX specific problem.

Comment by jluehe [ 14/Apr/10 ]

...

Comment by Shing Wai Chan [ 19/Apr/10 ]

...

Comment by kchung [ 07/Oct/10 ]

IBM JDK issue.

Comment by scatari [ 05/Apr/11 ]

Marking as to be fixed in 3.1.1.

Comment by Bhakti Mehta [ 15/Apr/11 ]

Changed to blocker as all QL failures are P1s now

Comment by Sivakumar Thyagarajan [ 18/Apr/11 ]

This issue appears to be a duplicate of GLASSFISH-16364, and is due to the non-availability of services specified through the ServiceProvider mechanism in IBM JDK. In this specific case, it is the FacesContextFactory service. Marking this as a duplicate.

Comment by Bhakti Mehta [ 20/Apr/11 ]

Sahoo's fix for 16364 fixed this issue http://gf-hudson.us.oracle.com/hudson/job/gf-3.1.1-aix-build/lastSuccessfulBuild/artifact/bundles/QL-GP-report.html





[GLASSFISH-16899] JSF is failing when tryint to read xhtml file which has many checkboxes Created: 23/Jun/11  Updated: 20/Dec/16  Resolved: 27/Jun/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.1_dev
Fix Version/s: 3.1.1_dev, 3.1.1, 4.0

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

All


Attachments: Java Source File GlassFish16899.java     File jsfapp.war     Zip Archive jsfapp.zip    
Tags: 3_1_1-approved

 Description   

Exception is as below:

[#|2011-06-20T22:04:01.795+0530|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=41;_ThreadName=http-thread-pool-8001(1);|StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
javax.faces.component.UpdateModelException: javax.el.ELException: javax.faces.FacesException: [collectionFromHintValues] Error: Expected value to be LinkedList
at javax.faces.component.UIInput.updateModel(UIInput.java:853)
at javax.faces.component.UIInput.processUpdates(UIInput.java:735)
at javax.faces.component.UIForm.processUpdates(UIForm.java:281)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1242)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:1231)
at com.sun.faces.lifecycle.UpdateModelValuesPhase.execute(UpdateModelValuesPhase.java:78)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
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:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
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: javax.el.ELException: javax.faces.FacesException: [collectionFromHintValues] Error: Expected value to be LinkedList
at javax.el.BeanELResolver.setValue(BeanELResolver.java:386)
at com.sun.faces.el.DemuxCompositeELResolver._setValue(DemuxCompositeELResolver.java:255)
at com.sun.faces.el.DemuxCompositeELResolver.setValue(DemuxCompositeELResolver.java:281)
at com.sun.el.parser.AstValue.setValue(AstValue.java:197)
at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:286)
at javax.faces.component.UIInput.updateModel(UIInput.java:818)
... 33 more
Caused by: javax.faces.FacesException: [collectionFromHintValues] Error: Expected value to be LinkedList
at com.sun.ts.tests.jsf.spec.render.common.SelectMany01Bean.setCollectionFromHintValues(SelectMany01Bean.java:202)
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.el.BeanELResolver.setValue(BeanELResolver.java:381)
... 38 more

#]


 Comments   
Comment by Bhavanishankar [ 23/Jun/11 ]

Please attach the test case.

Comment by naman_mehta [ 23/Jun/11 ]

Attached war file which can reproduce this error.

Download both file and compile and run GlassFish16899 test class.

javac -cp $GF_HOME/lib/embedded/glassfish-embedded-static-shell.jar GlassFish16899.java

java -cp $GF_HOME/lib/embedded/glassfish-embedded-static-shell.jar:. GlassFish16899

Comment by naman_mehta [ 23/Jun/11 ]

You can get following error under embedded glassfish:

com.sun.enterprise.web.VirtualServer$1 log
WARNING: StandardWrapperValve[jsp]: PWC1406: Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: Component ID selectmany01 has already been found in the view.
at com.sun.faces.util.Util.checkIdUniqueness(Util.java:821)
at com.sun.faces.application.StateManagerImpl.saveView(StateManagerImpl.java:136)
at javax.faces.application.StateManager.saveSerializedView(StateManager.java:207)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:615)
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:594)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:785)
at org.apache.jsp.forward_jsp._jspService(forward_jsp.java from :47)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
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:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
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)

Comment by Bhavanishankar [ 24/Jun/11 ]

Please attach the source code of the application.

Comment by naman_mehta [ 24/Jun/11 ]

Source code for attached war.

Comment by Bhavanishankar [ 27/Jun/11 ]

Why fix this issue in 3.1.1?

This is required for the fidelity of embedded glassfish.

Which is the targeted build of 3.1.1 for this fix?

b10

Do regression tests exist for this issue?

Yes – embedded devtests/fidelity tests.

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

As of now, QA does not run any tests for embedded glassfish. Moreover, this fix will not affect regular GlassFish. I will ensure stability by running all the automated devtests/fidelity tests for embedded.

Comment by scatari [ 27/Jun/11 ]

Approved for 3.1.1.

Comment by Bhavanishankar [ 27/Jun/11 ]

Fixed.





[GLASSFISH-16670] totalServletLoaded and ActiveServletsLoaded count always 0 Created: 17/May/11  Updated: 20/Dec/16  Resolved: 17/Nov/11

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1.1_dev
Fix Version/s: 3.1.1, 3.1.2, 4.0

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

Mac and hudson job showing the same results



 Description   

Turn on monitoring in GUI for web container, deploy a web app that has at least one servlet, hit the page and look at the statistics for the web app. The ActiveServletsLoaded and TotalServletsLoaded counts are always 0. The same can be determined by using the asadmin get command for that dotted name.

The monitoring data for session and jsp is correct.



 Comments   
Comment by Shing Wai Chan [ 18/May/11 ]

In both 3.2 and 3.1.1, I notice that the ServletStatsProvider is created as follows:
at org.glassfish.web.admin.monitor.ServletStatsProvider.<init>(ServletStatsProvider.java:100)
at org.glassfish.web.admin.monitor.WebStatsProviderBootstrap.registerApplicationStatsProviders(WebStatsProviderBootstrap.java:153)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java

Then in both case, WebModule.servletInitializedEvent is called.
The difference is that in the former case, ServletStatsProvider is invoked, but not for the latter.
Inside WebModule, servletProbeProvider=webContainer.getServletProbeProvider() which is just new ServletProbeProvider(); with empty method.

One need to investigate how the monitoring framework replace those empty methods with those from ServletStatsProvider.

Comment by Byron Nevins [ 23/May/11 ]

The new class-transforming code had a huge bug. If more than one listener class was "listening" to the same Probe, then the transformations done for listener#2 would wipeout the transformations for listener #1.

I.e. after transforming the transformer was removed from the Instrumentation object.
But the way the JVM works is that it ALWAYS starts from the class bytes on disk. If you transform it more than once you need to keep all those transformers in the Instrumentation object.

The fix was to remove one line of code where the transformer was removed.

Comment by Byron Nevins [ 05/Nov/11 ]

svn – 5/19/2011

46958
46959

Comment by Byron Nevins [ 05/Nov/11 ]

I spent WAY too much time digging through ancient emails looking for the history of this bugfix. I'm dumping it in here to avoid having to look again in the future.

Note that as of 11/5/2011 the changed file is EXACTLY the same in both the trunk and 3.1.2 branches.

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

Fixed a rather gigantic bug. Each PP class could only be transformed once. So if a PP had more than one listener – the last listener would
overwrite the transformed code triggered by the other listeners.
This solves the problems encountered in the admin devtests with totalservetsloaded counts.

Revisions:
----------
46958

Modified Paths:
---------------
branches/3.1.1/flashlight/framework/src/main/java/org/glassfish/flashlight/transformer/ProbeProviderClassFileTransformer.java

Diffs:
------
Index: branches/3.1.1/flashlight/framework/src/main/java/org/glassfish/flashlight/transformer/ProbeProviderClassFileTransformer.java
===================================================================
— branches/3.1.1/flashlight/framework/src/main/java/org/glassfish/flashlight/transformer/ProbeProviderClassFileTransformer.java (revision 46957)
+++ branches/3.1.1/flashlight/framework/src/main/java/org/glassfish/flashlight/transformer/ProbeProviderClassFileTransformer.java (revision 46958)
@@ -64,12 +64,9 @@
}
} catch (Exception e)

{ _logger.log(Level.WARNING, "Error during re-transformation", e); - }

finally {

  • if (_inst != null) { - _inst.removeTransformer(this); - }

    }

+ // note – do NOT remove the Transformer. If we transform it again we will need ALL transformers
}

@Override

Comment by Byron Nevins [ 17/Nov/11 ]

I'm guessing that this was reopened in order to set the fix version to 3.1.2
???





[GLASSFISH-16666] Some authorized methods can not be accessed on AIX Created: 17/May/11  Updated: 20/Dec/16  Resolved: 23/Jun/11

Status: Closed
Project: glassfish
Component/s: security
Affects Version/s: 3.1.1_dev
Fix Version/s: 3.1.1

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

AIX
IBM jdk1.6.0


Attachments: File server.log.noiorconfig    
Tags: 3_1_1-approved

 Description   

build: V3.1.1 build 054/b05
OS: AIX

Please note that this test only failed on AIX and it passed on all other OS/platforms. Thanks.

Steps to reproduce the bug:
1.Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT=:pserver:cvsguest@sunsw.us.oracle.com:/m/jws)
cd appserver-sqe
ant -f bootstrap.xml co-security
2. install GF V3.1.1, start domain domain1
3. Set env. variables
S1AS_HOME <GF installation dir> (example: /export/sonia/v3/glassfishv3/glassfish
SPS_HOME <workspace dir> (example: /export/sonia/appserver-sqe)
ANT_HOME <ant dir>
JAVA_HOME <java dir>
4. cd appserver-sqe/pe/security/noiorsecconfig/ejbmodule2, run "ant all", the test failed:
run-pe:
[echo] Running appclient
[exec] May 17, 2011 1:38:21 PM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[exec] WARNING: ACC013: The -password option is deprecated and will likely be removed in a future release. Please use -passwordfile or let the app client container prompt for the username and/or password if they are needed to access a remote resource.
[exec] WS HOME appserver-sqe
[exec] ejb stub =org.glassfish.appclient.client.acc.ACCClassLoader@55f355f3
[exec] ejb classname =com.sun.s1peqe.security.jsr115mr.runas.ejbmodule2.hello._HelloRemoteHome_DynamicStub
[exec] HelloRemoteHome org.glassfish.appclient.client.acc.ACCClassLoader@55f355f3
[exec] Looked up home!!
[exec] Narrowed home!!
[exec] Got the EJB!!
[exec] Generating report at /export/hudson/sonia/appserver-sqe/test_results.xml
[exec]
[exec]
[exec] -----------------------------------------
[exec] - noiorsecconfig-ejbmodule2-methodIsNotAuthorized: PASS -
[exec] - noiorsecconfig-ejbmodule2-methodIsAuthorized: FAIL -
[exec] -----------------------------------------
[exec] Total PASS: 1
[exec] Total FAIL: 1
[exec] Total DNR: 0
[exec] -----------------------------------------

– There are some exceptions in the server.log, please see attached server.log. Thanks.



 Comments   
Comment by scatari [ 07/Jun/11 ]

Pre-approving for 3.1.1 as this is a test blocker.

Comment by Nithya Ramakrishnan [ 23/Jun/11 ]

It appears that the test case has an issue which might be causing this error. In the file pe/security/noiorconfig/ejbmodule2/hello/descriptor/sun-ejb-jar.xml, Line no: 24, the <principal><name> has been commented out. This is causing the default-run-as principal to be something else other than linda, which is what the application is using to call the methodisAuthorized.
On uncommenting the line no: 24-26, the test case passes on AIX (makati.us.oracle.com)

[exec]
[exec] -----------------------------------------
[exec] - noiorsecconfig-ejbmodule2-methodIsNotAuthorized: PASS -
[exec] - noiorsecconfig-ejbmodule2-methodIsAuthorized: PASS -
[exec] -----------------------------------------
[exec] Total PASS: 2
[exec] Total FAIL: 0
[exec] Total DNR: 0
[exec] -----------------------------------------





[GLASSFISH-16774] Glassfish Installer - version string needs to be updated from 3.1 to 3.1.1 Created: 31/May/11  Updated: 20/Dec/16  Resolved: 30/Jun/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1.1_dev
Fix Version/s: 3.1.1

Type: Task Priority: Major
Reporter: Alex Pineda Assignee: Paul Davies
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux 5.3, build6 ogs-3.1.1-b06-unix.sh



 Description   

After installation of the Server and if one goes to the index page (http://localhost:8080), the version string says "GlassFish Server 3.1" which is not the correct version. The version should be updated to version 3.1.1



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 31/May/11 ]

This is not installation issue but bundled docs issue (since that's where index.html template comes from). Reassigning to docs team.

Comment by Paul Davies [ 31/May/11 ]

Doc team is already aware of the need for this change and plans to update the affected pages. Changing issue type to task.

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.





[GLASSFISH-16827] enable secure admin screen needs to display error to user Created: 09/Jun/11  Updated: 20/Dec/16  Resolved: 21/Sep/15

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1_dev
Fix Version/s: 3.1.1

Type: New Feature Priority: Critical
Reporter: Anissa Lam Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-scrubbed

 Description   

In the Enable Secure Admin screen, there are the 2 options for user to specify adminalias and instancealias.
IF there is problem with with is specified, the enable-secure-admin command fails.
In CLI, i see:

asadmin enable-secure-admin --adminalias alsdkflad --instancealias laskdjflasjkdf
remote failure: Error enabling secure admin : org.jvnet.hk2.config.TransactionFailure: com.sun.enterprise.security.admin.cli.SecureAdminCommand$SecureAdminCommandException: Error enabling secure admin; the keystore does not contain the specified aliases [alsdkflad, laskdjflasjkdf]
com.sun.enterprise.security.admin.cli.SecureAdminCommand$SecureAdminCommandException: Error enabling secure admin; the keystore does not contain the specified aliases [alsdkflad, laskdjflasjkdf]
Command enable-secure-admin failed.

However, in GUI, i don't see the error display, and DAS is restarted regardless.
We should ensure that the command returns successfully before restarting DAS, and display the error to user.



 Comments   
Comment by srinik76 [ 10/Jun/11 ]

Why fix this issue in 3.1.1?
Enable secure admin with wrong parameters does not fail thus misleading user

Which is the targeted build of 3.1.1 for this fix?
3.1.1_b08

Do regression tests exist for this issue?
Dev tests will be added

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

Comment by scatari [ 10/Jun/11 ]

Approved for 3.1.1.

Comment by Anissa Lam [ 14/Jun/11 ]

We will fix this issue in the trunk, since GLASSFISH-16126 will be removed from 3.1.1 branch.

Comment by srinik76 [ 15/Jun/11 ]

Will be done in future release and not in 3.1.1

Comment by Anissa Lam [ 15/Jun/11 ]

relating to new feature in 3.2

Comment by srinik76 [ 17/Jun/11 ]

Sending src/main/resources/appServer/securityAdmin.jsf
Sending src/main/resources/org/glassfish/common/admingui/Strings.properties
Transmitting file data ..
Committed revision 47541.

Checked into the v3 trunk





[GLASSFISH-16748] Upgrade Woodstox Created: 27/May/11  Updated: 20/Dec/16  Resolved: 13/Jun/11

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.1_dev
Fix Version/s: 3.1.1

Type: Improvement Priority: Major
Reporter: Harald Wellmann Assignee: ritzmann
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-approved

 Description   

I ran into a compatibility issue while porting a web app to Glassfish 3.1: Glassfish includes a rather old version 3.2.1 of Woodstox whereas my application uses Woodstox 4.1.1 which has some extra parser properties not available in Woodstox 3.2.1.

Is there a good reason for using this old version in Glassfish? If not, please upgrade.



 Comments   
Comment by Martin Matula [ 30/May/11 ]

Rama, can we upgrade to the latest Woodstox in GF 3.1.1? What are the risks?

Comment by ramapulavarthi [ 31/May/11 ]

Hi Martin,
I am not aware of any compatibility issues with woodstox 4.x (4.1.1). We can test it in JAX-WS and Metro workspaces first and run the tests and then try integrating in to GF.
Woodstox 4.x binaries are now osgified but that bundle has dependency on stax-api and stax2-api (new dependency in 4.x), where as in Glassfish we bundle the api together into one bundle. This might require some repackaging of bits.

CCing Fabian to the issue.

Comment by ritzmann [ 03/Jun/11 ]

A very quick test with just dropping in the Woodstox 4.1.1 binaries did not reveal any issues. Also this old issue GLASSFISH-11860 does not seem to be a problem.

Comment by ritzmann [ 09/Jun/11 ]

Integrated Woodstox 4.1.1 into Metro 2.1.1 branch. Will look at Metro 2.1.1 integration into GlassFish 3.1.1 next.

Comment by ritzmann [ 13/Jun/11 ]

Integrated Metro 2.1.1-b06 and Woodstox 4.1.1 into the 3.1.1 branch.





[GLASSFISH-16572] The following page should display the name of the resources to be consistent with other page. Created: 06/May/11  Updated: 20/Dec/16  Resolved: 17/Oct/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1
Fix Version/s: 3.1.1_dev, 3.1.1, 4.0

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

Tags: 3_1_1-approved, 3_1_1-scrubbed, 3_1_1-verified

 Description   
  • Target page of JDBC resource
  • Manage Target page of JDBC resource
  • Additional Properties of JDBC Connector Pool
  • Target page of Connector Resource
  • Additional properties of Connector Resource
  • Security Maps tab of Connector Resource
  • Target page of Admin Object Resource


 Comments   
Comment by Anissa Lam [ 18/May/11 ]

Will be nice to get this in for 3.1.1. But i add the tag 3_1-next which means not committed.

Comment by sumasri [ 23/May/11 ]

Why fix this issue in 3.1.1?
o Resource name and pool name is not present in some page which is inconsistent with other pages.

Which is the targeted build of 3.1.1 for this fix?
o MS4

Do regression tests exist for this issue?
o No. Manual testing should be sufficient

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
o verify the bug reported is fixed

Diffs:

Index: common/src/main/resources/resourceNode/resourceNameSection.inc
===================================================================
— common/src/main/resources/resourceNode/resourceNameSection.inc (revision 0)
+++ common/src/main/resources/resourceNode/resourceNameSection.inc (revision 0)
@@ -0,0 +1,51 @@
+<!--
+
+ DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
+
+ Copyright (c) 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
+ and Distribution License("CDDL") (collectively, the "License"). You
+ may not use this file except in compliance with the License. You can
+ obtain a copy of the License at
+ https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
+ or packager/legal/LICENSE.txt. See the License for the specific
+ language governing permissions and limitations under the License.
+
+ When distributing the software, include this License Header Notice in each
+ file and include the License file at packager/legal/LICENSE.txt.
+
+ GPL Classpath Exception:
+ Oracle designates this particular file as subject to the "Classpath"
+ exception as provided by Oracle in the GPL Version 2 section of the License
+ file that accompanied this code.
+
+ Modifications:
+ If applicable, add the following below the License Header, with the fields
+ enclosed by brackets [] replaced by your own identifying information:
+ "Portions Copyright [year] [name of copyright owner]"
+
+ Contributor(s):
+ If you wish your version of this file to be governed by only the CDDL or
+ only the GPL Version 2, indicate your decision by adding "[Contributor]
+ elects to include this software in this distribution under the [CDDL or GPL
+ Version 2] license." If you don't indicate a single choice of license, a
+ recipient has the option to distribute your version of this file under
+ either the CDDL, the GPL Version 2 or to extend the choice of license to
+ its licensees as provided above. However, if you add GPL Version 2 code
+ and therefore, elected the GPL Version 2 license, then the option applies
+ only if the new code is made subject to such option by the copyright
+ holder.
+
+-->
+
+ <sun:propertySheet id="resourceNameSheet">
+ <!-- Resource Name Field section -->
+ <sun:propertySheetSection id="propertySectionTextField">
+ <sun:property id="resourceNameProp" labelAlign="left" noWrap="#

{true}" overlapLabel="#{false}" label="$resource{i18n.common.jndiName}" >
+ <sun:staticText id="resourceName"text="#{pageSession.resourceName}" />
+ </sun:property>
+ </sun:propertySheetSection>
+ </sun:propertySheet>
+ "<br/>
Index: common/src/main/resources/resourceNode/poolNameSection.inc
===================================================================
— common/src/main/resources/resourceNode/poolNameSection.inc (revision 0)
+++ common/src/main/resources/resourceNode/poolNameSection.inc (revision 0)
@@ -0,0 +1,51 @@
+<!--
+
+ DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
+
+ Copyright (c) 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
+ and Distribution License("CDDL") (collectively, the "License"). You
+ may not use this file except in compliance with the License. You can
+ obtain a copy of the License at
+ https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
+ or packager/legal/LICENSE.txt. See the License for the specific
+ language governing permissions and limitations under the License.
+
+ When distributing the software, include this License Header Notice in each
+ file and include the License file at packager/legal/LICENSE.txt.
+
+ GPL Classpath Exception:
+ Oracle designates this particular file as subject to the "Classpath"
+ exception as provided by Oracle in the GPL Version 2 section of the License
+ file that accompanied this code.
+
+ Modifications:
+ If applicable, add the following below the License Header, with the fields
+ enclosed by brackets [] replaced by your own identifying information:
+ "Portions Copyright [year] [name of copyright owner]"
+
+ Contributor(s):
+ If you wish your version of this file to be governed by only the CDDL or
+ only the GPL Version 2, indicate your decision by adding "[Contributor]
+ elects to include this software in this distribution under the [CDDL or GPL
+ Version 2] license." If you don't indicate a single choice of license, a
+ recipient has the option to distribute your version of this file under
+ either the CDDL, the GPL Version 2 or to extend the choice of license to
+ its licensees as provided above. However, if you add GPL Version 2 code
+ and therefore, elected the GPL Version 2 license, then the option applies
+ only if the new code is made subject to such option by the copyright
+ holder.
+
+-->
+
+ <sun:propertySheet id="resourceNameSheet">
+ <!-- Connection Pool Name Field section -->
+ <sun:propertySheetSection id="propertySectionTextField">
+ <sun:property id="resourceNameProp" labelAlign="left" noWrap="#{true}

" overlapLabel="#

{false}" label="$resource{i18n.common.poolName}" >
+ <sun:staticText id="resourceName"text="#{pageSession.Name}" />
+ </sun:property>
+ </sun:propertySheetSection>
+ </sun:propertySheet>
+ "<br/>
Index: common/src/main/resources/resourceNode/resourceEditTargets.jsf
===================================================================
— common/src/main/resources/resourceNode/resourceEditTargets.jsf (revision 47043)
+++ common/src/main/resources/resourceNode/resourceEditTargets.jsf (working copy)
@@ -54,6 +54,7 @@
<event>
<!beforeCreate
getRequestValue(key="name" value="#{pageSession.Name}");
+ setPageSessionAttribute(key="resourceName" value="#{pageSession.Name}");
urlencode(value="#{pageSession.Name}" encoding="UTF-8" result="#{pageSession.encodedName}");
//For resourceEditTabs.inc
setSessionAttribute(key="resEditTabs" value="targetTab");
@@ -68,7 +69,7 @@
#include "/common/shared/alertMsg.inc"
<sun:title id="propertyContentPage" title="$resource{i18n.resourceTargetListing.PageTitle}" helpText="$resource{i18n.resourceTargetListing.PageTitleHelp}"/>
"<br />
-
+#include "/common/resourceNode/resourceNameSection.inc"
<sun:table id="targetTable" title="$resource{i18n.common.TargetTableTitle}" sortPanelToggleButton="#{false}

"
deselectMultipleButton="$boolean

{true}

"
deselectMultipleButtonOnClick="setTimeout('admingui.table.changeThreeTableButtons(\\\\\'#

{pageSession.topActionGroup}

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

{pageSession.tableId}

\\\\\');', 0)"
Index: common/src/main/resources/resourceNode/resourceManageTargets.jsf
===================================================================
— common/src/main/resources/resourceNode/resourceManageTargets.jsf (revision 47043)
+++ common/src/main/resources/resourceNode/resourceManageTargets.jsf (working copy)
@@ -53,6 +53,7 @@
<!beforeCreate
getRequestValue(key="resName" value="#

{pageSession.resName}");
getRequestValue(key="generalPage" value="#{pageSession.generalPage}");
+ setPageSessionAttribute(key="resourceName" value="#{pageSession.resName}

");
urlencode(value="#

{pageSession.resName}

" encoding="UTF-8" result="#

{pageSession.encodedResName}

");
#include "/common/shared/targetsList.inc"
setPageSessionAttribute(key="resTargets" value={});
@@ -136,6 +137,7 @@
</sun:panelGroup>
</facet>
</sun:title>
+#include "/common/resourceNode/resourceNameSection.inc"
<event>
<!afterCreate
getUIComponent(clientId="#

{formId}

" component=>$attribute

{component}

)
Index: jca/src/main/resources/connectorSecurityMaps.jsf
===================================================================
— jca/src/main/resources/connectorSecurityMaps.jsf (revision 47043)
+++ jca/src/main/resources/connectorSecurityMaps.jsf (working copy)
@@ -72,7 +72,7 @@
<sun:title id="propertyContentPage" title="$resource

{i18njca.connectorSecurityMaps.pageTitle}

"
helpText="$resource

{i18njca.connectorSecurityMaps.pageTitleHelp}

" />
"<br /> <br />
-
+#include "/common/resourceNode/poolNameSection.inc"
#include "/jca/securityMapsTable.inc"

<sun:hidden id="helpKey" value="$resource

{help_jca.connectorSecurityMaps}

" />
Index: jca/src/main/resources/connectorConnectionPoolProperty.jsf
===================================================================
— jca/src/main/resources/connectorConnectionPoolProperty.jsf (revision 47043)
+++ jca/src/main/resources/connectorConnectionPoolProperty.jsf (working copy)
@@ -106,6 +106,7 @@
</facet>
</sun:title>
"<br>
+#include "/common/resourceNode/poolNameSection.inc"
#include "/common/shared/propertyDescTable.inc"

<sun:hidden id="helpKey" value="$resource

{help_jca.connectorConnectionPoolProperty}

" />
Index: jdbc/src/main/resources/jdbcConnectionPoolProperty.jsf
===================================================================
— jdbc/src/main/resources/jdbcConnectionPoolProperty.jsf (revision 47043)
+++ jdbc/src/main/resources/jdbcConnectionPoolProperty.jsf (working copy)
@@ -104,6 +104,7 @@

</sun:title>
"<br>
+#include "/common/resourceNode/poolNameSection.inc"
#include "/common/shared/propertyDescTable.inc"
<sun:hidden id="helpKey" value="$resource

{help_jdbc.jdbcConnectionPoolProperty}

" />
</sun:form>

Comment by scatari [ 23/May/11 ]

Approved for 3.1.1.

Comment by Anissa Lam [ 24/May/11 ]

Change looks good. Please check into both trunk & 3.1.1 branch.

Comment by sumasri [ 25/May/11 ]

Added resource name in all resources targets page and manage targets pages.
Added pool name in jdbc connection pool property page, connector connection pool property and security maps pages.

Checked in to both trunk and branch 3.1.1

Comment by shaline [ 22/Jun/11 ]

Verified on 3.1.1 promoted b08.

Comment by Anissa Lam [ 17/Oct/11 ]

re-open issue to mark the fixed version.

Comment by Anissa Lam [ 17/Oct/11 ]

mark fixed for 4.0 (trunk) and 3.1.1

Comment by Anissa Lam [ 17/Oct/11 ]

close issue again.





[GLASSFISH-17002] Embedded GlassFish fails to retrieve client stub JAR file Created: 08/Jul/11  Updated: 20/Dec/16  Resolved: 11/Jul/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1.1, 4.0
Fix Version/s: 3.1.1_dev, 3.1.1, 4.0

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

ANY


Attachments: File simple-ejb-cdiApp.ear    
Tags: 3_1_1-approved

 Description   

If an EAR containing EJB and AppClient is deployed with '--retrieve' option in Embedded GlassFish, the client stub JAR file is not retrieved. The deployment causes

java.lang.NullPointerException
        at org.glassfish.deployment.admin.DeployCommand.retrieveArtifacts(DeployCommand.java:718)
        at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:434)

Reproducible with a simple test:

import java.io.*;
import org.glassfish.embeddable.*;

public class Test {

  public static void main(String... args) throws Exception {

    BootstrapProperties bp = new BootstrapProperties();
    bp.setInstallRoot(System.getenv("S1AS_HOME"));
    GlassFishRuntime gfr = GlassFishRuntime.bootstrap(bp);
   
    GlassFishProperties gp = new GlassFishProperties();
    gp.setInstanceRoot(System.getenv("S1AS_HOME") + "/domains/domain1");
    GlassFish gf = gfr.newGlassFish(gp);
    gf.start();

    Deployer deployer = gf.getDeployer();
    String appName = deployer.deploy(new File("simple-ejb-cdiApp.ear"), "--retrieve=/tmp");
    System.out.println("Deployed [ " + appName + " ]");

    gf.dispose();
    gfr.shutdown();

  }
}

Run with $S1AS_HOME/lib/embedded/glassfish-embedded-static-shell.jar.

simple-ejb-cdiApp.ear is attached.



 Comments   
Comment by Bhavanishankar [ 08/Jul/11 ]

Why fix this issue in 3.1.1?
important use case to be able to run appclients in embedded glassfish.

Which is the targeted build of 3.1.1 for this fix?
b11

Do regression tests exist for this issue?
yes.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
none. all tests are run in developer's hudson.

Comment by Tim Quinn [ 08/Jul/11 ]

A note to Bhavani...

The problem seems to be that the invocation's outbound payload is never created. CommandRunnerImpl creates the AdminCommandContext and uses the invocation's outbound and inbound payloads to assign those fields in the context. That outbound payload is used for delivering generated artifacts back to the admin client.

Comment by Bhavanishankar [ 08/Jul/11 ]

Thanks Tim. Yes, you are spot on.

I kind of have the tentative fix as below in the embedded' deployerimpl to retrieve the payload:


        Payload.Outbound outboundPayload = null;
        String retrieve = commandParams.getOne("retrieve");
        if(retrive != null && new File(retrieve).exists()) {
            outboundPayload = PayloadImpl.Outbound.newInstance();
        }

        inv.outbound(outboundPayload);
        inv.parameters(commandParams).execute();

        if (outboundPayload != null) {
            try {
                File payLoadZIp = File.createTempFile("gfembed", ".zip");
                payLoadZIp.deleteOnExit();
                FileOutputStream fout = new FileOutputStream(payLoadZIp);
                outboundPayload.writeTo(fout);
                fout.flush();
                fout.close();
                new com.sun.enterprise.util.zip.ZipFile(payLoadZIp, new File(retrive)).explode();
            } catch (Exception ex) {
                logger.warning(ex.getMessage());
            }
        }


Comment by Bhavanishankar [ 11/Jul/11 ]

Fixed.

http://java.net/projects/glassfish/lists/commits/archive/2011-07/message/154
http://java.net/projects/glassfish/lists/commits/archive/2011-07/message/155
http://java.net/projects/glassfish/lists/commits/archive/2011-07/message/156





[GLASSFISH-20816] server.log not updating Created: 18/Sep/13  Updated: 20/Dec/16  Resolved: 27/Jan/14

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1.1_dev
Fix Version/s: 3.1.1

Type: Bug Priority: Major
Reporter: sh4m Assignee: sandeep.shrivastava
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.1 ( build 12 )
SPARC 10
Java 1.6.0_43


Tags: admin-gui, log

 Description   

server.log not updating anything once all the domain/app finish startup. It should show some activity/info when i try to access my application, however It just keep freezing after that.

This only happen on my SunSolaris Server. SPARC10. My red hat server is doing fine.

below is sample of my server.log.

[#|2013-09-02T11:20:14.444+0300|INFO|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=Thread-2;|GlassFish Server Open Source Edition 3.1.1 (12) st
artup time : Felix (16,905ms), startup services(451,396ms), total(468,301ms)|#]

[#|2013-09-02T11:20:14.810+0300|INFO|glassfish3.1.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=20;_ThreadName=Thread-2;|JMXStartupService: Started JMXConnector, JMXService
URL = service:jmx:....

[#|2013-09-02T11:20:16.236+0300|INFO|glassfish3.1.1|org.hibernate.validator.engine.resolver.DefaultTraversableResolver|_ThreadID=21;_ThreadName=Thread-2;|Instantiated an instance of org.hibernate
.validator.engine.resolver.JPATraversableResolver.|#]

[#|2013-09-02T11:20:16.902+0300|INFO|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=22;_ThreadName=Thread-2;|The Admin Console is already installed, but
not yet loaded.|#]

[#|2013-09-02T11:20:16.907+0300|INFO|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=22;_ThreadName=Thread-2;|The Admin Console is starting. Please wait.

#]

[#|2013-09-02T11:20:17.122+0300|INFO|glassfish3.1.1|javax.enterprise.system.tools.admin.com.sun.enterprise.container.common|_ThreadID=23;_ThreadName=Thread-2;|User [] from host ...
does not have administration access|#]

[#|2013-09-02T11:20:26.492+0300|INFO|glassfish3.1.1|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=22;_ThreadName=Thread-2;|Initializing Mojarra 2.1.3 (FCS b02) for context ''|#]

[#|2013-09-02T11:20:31.671+0300|INFO|glassfish3.1.1|org.hibernate.validator.engine.resolver.DefaultTraversableResolver|_ThreadID=22;_ThreadName=Thread-2;|Instantiated an instance of org.hibernate
.validator.engine.resolver.JPATraversableResolver.|#]

[#|2013-09-02T11:20:37.215+0300|INFO|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=22;_ThreadName=Thread-2;|WEB0671: Loading application [__admingui] at [/
]|#]

[#|2013-09-02T11:20:37.223+0300|INFO|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=22;_ThreadName=Thread-2;|CORE10010: Loading application __admingui done in
20,313 ms|#]

[#|2013-09-02T11:20:37.226+0300|INFO|glassfish3.1.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=22;_ThreadName=Thread-2;|The Admin Console application is loaded.|#]

any advice?



 Comments   
Comment by Anissa Lam [ 18/Sep/13 ]

You are talking that server.log is not updated, this is not related to admin console.
Assign to 'logging' for evaluation.

Comment by pires [ 24/Sep/13 ]

I'm having the same problem as described at ://www.java.net/forum/topic/glassfish/glassfish/gf4-applications-logs-dont-show-node-logs-clustered-environment

I'm currently on Ubuntu 12.04.3 64-bit, running OpenJDK 7.
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.12.04.2)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

Comment by sandeep.shrivastava [ 26/Sep/13 ]

Do you have the thread dumps available of the stuck server?

Thanks

Comment by sh4m [ 26/Sep/13 ]

Hi sandeep,

can you give me some instruction how to get this thread dump? im using sun solaris 10.

Comment by sandeep.shrivastava [ 26/Sep/13 ]

You can try jstack <pid>. Please also post the GlassFish version and the java -version details.

Thanks

Comment by sh4m [ 26/Sep/13 ]

jstack command not found.. but i use asadmin to generate the thread. asadmin generate-jvm-report --type=thread

i dont know how to attach the file.. the output is inside here http://pastebin.com/8STy2hHc

is it enough?

Comment by sandeep.shrivastava [ 26/Sep/13 ]

Yes. Based on what you have posted, there is no deadlock and logging is also not stuck.

Comment by sh4m [ 21/Oct/13 ]

Hi sandeep,

is there any work around for this issue? very hard to debug if the server.log not updating anything...

Comment by sandeep.shrivastava [ 21/Oct/13 ]

Is there a way to reproduce this issue? Could you provide a test app and steps to replicate this with the configuration details required?

Thanks

Sandeep

Comment by sh4m [ 27/Jan/14 ]

Hi Sandeep,

i just found that Java version 1.6.0_43 is cause the problem. So i use the 1.6.0_38 and then re-install glassfish and application, the server.log is working fine now.

Comment by sandeep.shrivastava [ 27/Jan/14 ]

Great. Thanks for the investigation and verification. I am marking this as closed.





[GLASSFISH-15185] Inline help: CONFIG node information populated during create-local-instance Created: 14/Dec/10  Updated: 19/Dec/16  Resolved: 30/Jun/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1

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

Tags: 312_verified

 Description   

We should add information on the New Node and Edit Node screens that the following fields: Node Host, Node Directory and Installation Directory do not need to be filled in, for a CONFIG type node, and will be populated during instance creation.



 Comments   
Comment by Paul Davies [ 14/Dec/10 ]

I will make this change in the online help, not the inline help.

Comment by Paul Davies [ 28/Dec/10 ]

Fixed in revision 44123.

Comment by lidiam [ 04/Mar/11 ]

Checked in build b43 and on the Edit Node relevant page the information is there for Node Host but not for Node Directory not Installation Directory. New Node page has this information for all three cases thus I'll lower priority.

Comment by Paul Davies [ 07/Mar/11 ]

For Edit Node, it's not so simple: If instances are already added to an existing node and the node directory and the installation directory are defined, it's probably not a good idea to clear the Node Directory and Installation Directory fields. For Edit Node, this information was omitted for precisely this reason.

If the help for Edit Node is to be changed, the description should probably state that these these fields should be left empty for a CONFIG node only if they are not already set to some value.

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in 3.1.1

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.

Comment by lidiam [ 20/Jan/12 ]

Verified in build ogs-3.1.2-b18.zip.





[GLASSFISH-16025] Domain.xml: setting protocol.http-listener-1.http.max-connections set in 1 or -1 Created: 16/Feb/11  Updated: 19/Dec/16  Resolved: 13/Dec/11

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1

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

Windows XP


Tags: 3_1-release-note-added, 3_1-release-notes

 Description   

Hi there,

with old documentaton for GF 3.0.1 I found that :

"http.max-connections property (optional) Specifies the maximum number of requests that can be pipelined until the connection is closed by the server. Set this property to 1 to disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelined until the connection is closed by the server. A value of 0 means requests are always rejected. A value of -1 sets no limit to the number of keep-alive connections. "

Now I use the GF 3.1 (build 42) and I set protocol.http-listener-1.http.max-connections set into 1 and seems that connections are not closed(they are keep-alive). Is such behaviour correct?

When I set into -1, all connections are closed, but I am expecting to see them alive.

Could anybody explain how this setting works now for version 3.1?

Thank you



 Comments   
Comment by oleksiys [ 21/Feb/11 ]

it's a bug.

Workaround is following:

-1 is not working as unlimited, please use some big number up to Integer.MAX_VALUE.
1 - will let you process 1 keep-alive request, and close the connection after processing 2nd request on the same connection
0 - will disable keep-alive for the connection

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by oleksiys [ 13/Dec/11 ]

mark as fixed





[GLASSFISH-15725] Admin GUI: include default-config, server-config in online help Created: 27/Jan/11  Updated: 19/Dec/16  Resolved: 30/Jun/11

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

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   

Admin GUI online help - doesn't talk about default-config and server-config.

On "Configurations" page, please add a topic about out-of-the-box existence and special status of default-config and server-config, with a link to UB docs.



 Comments   
Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in the 3.1.1 bundled docs.

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.





[GLASSFISH-15800] typo in built-in asadmin docs "export-htp-lb-config" Created: 02/Feb/11  Updated: 19/Dec/16  Resolved: 30/Jun/11

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

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


 Description   

The synopsis section of export-http-lb-config incorrectly spells it as "export-htp-lb-config":

NAME
export-http-lb-config - exports the load balancer configura-
tion or load balancer to a file

SYNOPSIS
export-htp-lb-config [--help] --config config_name | --lbname load_balancer_name [--target target] [--retrieve=false] [file_name]

...



 Comments   
Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in 3.1.1

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.





[GLASSFISH-15810] LB plugin installer for GF 3.1 should only support Oracle iPlanet Webserver 7 Created: 03/Feb/11  Updated: 19/Dec/16  Resolved: 21/Oct/11

Status: Resolved
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1

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


 Description   

If the plugin installer/configurator is only meant to support Web Server 7, it should not ask for confirmation that Oracle iPlanet Web Server installation is version 7 or not, and in fact it should probably report an error if its pointed at a 6.1 installation.

I know that the plugin code right now is shared between 2.x and 3.x, but the majority of the customers on 2.x will use the main product's installer to install the plugin, and not the standalone lb installer.



 Comments   
Comment by kshitiz_saxena [ 13/Jun/11 ]

Fix is available in 3.1.1.

Comment by kshitiz_saxena [ 21/Oct/11 ]

Issue was fixed in 3.1.1.





[GLASSFISH-15812] LB Plugin Installer should add platform specific libs to envvars script for Apache installs Created: 03/Feb/11  Updated: 19/Dec/16  Resolved: 21/Oct/11

Status: Resolved
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1

Type: Improvement Priority: Minor
Reporter: tecknobabble Assignee: kshitiz_saxena
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1, glassfish, ssl

 Description   

On Solaris systems, the mod_loadbalancer.so plugin depends on shared libraries in /usr/lib/mps, for example libssl3.so.

Either:
1) The lb plugin should detect that /usr/lib/mps is present and add it to the LD_LIBRARY_PATH when it updates the envvars script.
or
2) The mod_loadbalancer.so should be linked with -R with /usr/lib/mps in the path list so that the shared library has that dependency embedded in it.



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

Need more info to add issue to 3.1 Release Notes.

Comment by tecknobabble [ 25/Mar/11 ]

Not sure why its flagged as a release note issue.

I raised this as part of the doc review on the HA Guide, specifically this section:

http://download.oracle.com/docs/cd/E18930_01/html/821-2426/abdhg.html#gidfs

where it states:

"To configure the Apache 2.2.x security files to work with the Loadbalancer Plugin, append /usr/lib/mps to the LD_LIBRARY_PATH in the apache-install-dir/bin/envvars file."

Honestly, the LB installer should be able to check to see if that directory exists and update the envvars script itself. This shouldn't be a manual step. The more the installer can do the better to eliminate the chance of human error. With the 2.x installer I believe it made all the requisite changes for configuring Apache with the LB plugin.

Comment by Scott Fordin [ 13/Apr/11 ]

Sounds like this does not need to be added to the Release Notes as it is already documented in the location to which tecknobabble points. Removing Release Notes tag.

Comment by kshitiz_saxena [ 13/Jun/11 ]

Fix is not needed in 3.1.1 as SSL libraries are bundled along with load-balancer plugin in 3.1.1.

Comment by kshitiz_saxena [ 21/Oct/11 ]

This issue is no longer reproducible in 3.1.1 as SSL libraries to distribution.

Comment by kshitiz_saxena [ 21/Oct/11 ]

Reopened to add fix version

Comment by kshitiz_saxena [ 21/Oct/11 ]

Fixed in version 3.1.1.





[GLASSFISH-15869] JPADeployer throws NPE while deploying hybrid application contaning persistence.xml using asadmin command Created: 06/Feb/11  Updated: 19/Dec/16  Resolved: 21/Apr/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1, 4.0

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

Attachments: File rfc143.test4.war    
Tags: 3_1-exclude

 Description   

Try deploying the attached war as:
asadmin deploy --type=osgi rfc143.test4.war
Although it deploys fine, there is actually an NPE in the server.log:

[#|2011-02-06T22:50:33.384+0530|WARNING|glassfish3.1|javax.enterprise.system.core.org.glassfish.kernel.event|_ThreadID=157;_ThreadName=admin-thread-pool-4848(5);|Exception while dispatching an event
java.lang.NullPointerException
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:472)
at org.glassfish.persistence.jpa.JPADeployer.iterateInitializedPUsAtApplicationPrepare(JPADeployer.java:453)
at org.glassfish.persistence.jpa.JPADeployer.event(JPADeployer.java:377)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:452)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:372)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
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: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:619)

#]

The root cause here is that JPADeployer assumes there always exists a RootDeploymentDescriptor, which is not correct as in this case. There was a similar bug in ejb container as well. The fix is really simple as the patch below shows:

Index: persistence/jpa-connector/src/main/java/org/glassfish/persistence/jpa/JPADeployer.java
===================================================================
— persistence/jpa-connector/src/main/java/org/glassfish/persistence/jpa/JPADeployer.java (revision 44807)
+++ persistence/jpa-connector/src/main/java/org/glassfish/persistence/jpa/JPADeployer.java (working copy)
@@ -468,7 +468,7 @@
// We are being called for an application
currentBundle = context.getModuleMetaData(Application.class);
}
-
+ if (currentBundle == null) return;
Collection<PersistenceUnitsDescriptor> pusDescriptorForThisBundle = currentBundle.getExtensionsDescriptors(PersistenceUnitsDescriptor.class);
for (PersistenceUnitsDescriptor persistenceUnitsDescriptor : pusDescriptorForThisBundle) {
for (PersistenceUnitDescriptor pud : persistenceUnitsDescriptor.getPersistenceUnitDescriptors()) {

Since this is not a critical bug, as the NPE is itself not causing deployment to fail, this has been excluded from 3.1 release.



 Comments   
Comment by Sanjeeb Sahoo [ 21/Apr/11 ]

The exception has changed slightly in 3.2 trunk builds:

[#|2011-04-21T23:37:40.167+0530|WARNING|glassfish3.2|javax.enterprise.system.core.org.glassfish.kernel.event|_ThreadID=25;_ThreadName=admin-thread-pool-4848(3);|Exception while dispatching an event
java.lang.NullPointerException
at com.sun.enterprise.deployment.util.DOLUtils.getCurrentBundleForContext(DOLUtils.java:122)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:478)
at org.glassfish.persistence.jpa.JPADeployer.iterateInitializedPUsAtApplicationPrepare(JPADeployer.java:465)
at org.glassfish.persistence.jpa.JPADeployer.event(JPADeployer.java:389)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:453)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:390)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:357)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:372)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1071)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:98)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1251)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1239)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:455)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
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:238)
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:619)

#]

Now, the fix is needed in both in JPADeployer and DOLUtils. I am taking ownership of this bug and will fix it soon.

Comment by Sanjeeb Sahoo [ 21/Apr/11 ]

Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/util/DOLUtils.java
Sending persistence/jpa-connector/src/main/java/org/glassfish/persistence/jpa/JPADeployer.java
Transmitting file data ..
Committed revision 46306.

Comment by Sanjeeb Sahoo [ 15/Oct/11 ]

It has been backported to 3.1.1 as a side effect of some other merge done by someone else. So, I don't have the details. But, I can't reproduce the bug against 3.1.1, so it is definitely fixed in 3.1.1.





[GLASSFISH-15853] [UB]ctrl-c in multimode kills domain started from same multimode session Created: 04/Feb/11  Updated: 19/Dec/16  Resolved: 30/Jun/11

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

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

Attachments: HTML File end-multimode.html    
Tags: 3_1-exclude

 Description   

If you start the domain from inside asadmin in multimode, then exiting asadmin, with Ctrl-C kills the running domain:

asadmin> version --verbose
Version string could not be obtained from Server [localhost:3108] for some reason.
(Turn debugging on e.g. by setting AS_DEBUG=true in your environment, to see the details).
Using locally retrieved version string from version class.
Version = Oracle GlassFish Server 3.1 (build 40)
asadmin Java Runtime Environment version: 1.6.0_21
Command version executed successfully.

asadmin> start-domain
Waiting for domain1 to start ...............................
Successfully started the domain : domain1
domain Location: /support/sfw/gf31/glassfish/domains/domain1
Log File: /support/sfw/gf31/glassfish/domains/domain1/logs/server.log
Admin Port: 3108
Command start-domain executed successfully.
asadmin> ^C

$ asadmin list-domains
domain1 not running
Command list-domains executed successfully.

If you use "exit" to exit the asadmin session the domain is also left running.
Ctrl-C didn't do this in GF 2.x, but did in 8.x.



 Comments   
Comment by Bill Shannon [ 04/Feb/11 ]

I don't know how to solve this without native code.

The signal is going to be sent to every process in the tty's process
group, which includes the server process. I believe native code is
required to put the server in a different process group.

The simple workaround is, don't use ^C to exit multimode. Use the
exit command or ^D. You're not trying to kill it, you're just trying
to exit it.

Comment by Nazrul [ 04/Feb/11 ]

This is not a stopper. Excluding from 3.1

Comment by Byron Nevins [ 22/Mar/11 ]

Document this behavior...

Comment by Paul Davies [ 22/Mar/11 ]

The procedure in the 3.1 Administration Guide at http://download.oracle.com/docs/cd/E18930_01/html/821-2416/giobi.html#givjn for ending a multimode session lists only the following commands and key combinations (note the absence of Ctrl-C from this list):

  • exit
  • quit
  • UNIX and Linux systems: Ctrl-D
  • Windows systems: Ctrl-Z

So, it could be argued that the operation reported in this issue is unsupported. That said, it probably wouldn't hurt to add a note to the procedure to tell users to avoid using Ctrl-C, explaining why.

Comment by tecknobabble [ 22/Mar/11 ]

Thanks Paul, just highlighting the effects of ctrl-c would be helpful - this was the basis of a customer escalation on an earlier version of the product, and having a "don't do" it in black and white will help with the change in behaviour from 2.x.

Comment by Paul Davies [ 19/May/11 ]

As we're fixing unbundled doc bugs for 3.1.1, we can fix this bug then.

Comment by Paul Davies [ 26/May/11 ]

[UB]: Denotes unbundled documentation

Comment by Paul Davies [ 30/Jun/11 ]

Fix is contained in the attached fiile and will be published in the next update of the documentation.





[GLASSFISH-15998] Man page for list-supported-cipher-suites Created: 15/Feb/11  Updated: 19/Dec/16  Resolved: 11/Jul/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1

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

Tags: 3_1-exclude

 Description   

The man page of list-supported-cipher-suites lists the kerberos cipher (KRB5) suites. But the command output does not list them.

here is the command output :

SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA

Note: many months ago the CLI code was fixed to explicitly exclude the Kerberos ones. But i guess this was not communicated explicitly to docs team.



 Comments   
Comment by Paul Davies [ 16/Feb/11 ]

Too late for 3.1.

Comment by Scott Fordin [ 17/Mar/11 ]

Added the topic to 3.1 Release Notes. Will correct the man page in the 3.2 build. Removing release notes tag from the issue now.

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in the 3.1.1 bundled docs

Comment by Scott Fordin [ 31/May/11 ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 07/Jun/11 ]

Reassigned to security writer.

Comment by kevinmcd [ 14/Jun/11 ]

I have removed the KRB5 cipher suites from the manpage. I'll update the status when this version of the manpage is available.

Comment by kevinmcd [ 11/Jul/11 ]

Change appears in svn revision 47759, which I checked in the nightly build of 07-Jul-2011.





[GLASSFISH-15999] Description of create-jacc-provider references JSR196 but the command has nothing to do with JSR196 and JAAS Created: 15/Feb/11  Updated: 19/Dec/16  Resolved: 11/Jul/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1

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

Tags: 3_1-exclude

 Description   

The description of create-jacc-provider references JSR196 and JAAS but it has nothing to do with those specs.

Here is what the Description should look like :

The create-jacc-provider subcommand creates a JSR-115
compliant Java Authorization Contract for Containers (JACC)
provider that can be used for authorization of applications
running in GlassFish Server. The JACC provider is created as
a jacc-provider element within the security-service element
in the domain's domain.xml file.

The default GlassFish Server installation includes two JACC
providers, named default and simple. Any JACC providers
created with the create-jacc-provider subcommand are in
addition to these two default providers. The default GlassF-
ish Server JACC providers implement a simple, file-based
authorization engine that complies with the JACC specifica-
tion. The create-jacc-provider subcommand makes it possible
to specify additional third-party JACC providers.

Any number of jacc-provider's can be created under the security-service
but the GlassFish runtime would use one of them at any given point. The jacc
attribute on the security-service points to the name of the provider that is
currently in use by glassfish. Any change to the jacc attribute (to make it
point to a different jacc-provider) would require restart of the server.
This command is supported in remote mode only.



 Comments   
Comment by kumarjayanti [ 15/Feb/11 ]

there is also some extra "\fR" character appearing in the sample commandline, not sure if this is some standard way of showing things. IMO it should be cleaned up.

---------current----
asadmin> create-jacc-provider \fR
--policyproviderclass com.sun.enterprise.security.provider.PolicyWrapper
--policyconfigfactoryclass com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl
-------------------

should be :

asadmin> create-jacc-provider
--policyproviderclass com.sun.enterprise.security.provider.PolicyWrapper
--policyconfigfactoryclass com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl

Comment by kumarjayanti [ 15/Feb/11 ]

In the description of delete-jacc-provider please reword the following paragraph :

--------
Authorization modules that depend on the JACC provider to be
deleted should be reconfigured to work with an alternate
provider before the deletion.

---------

TO

--------
The JACC provider used by GlassFish for authorization is specified by the jacc attribute on the security-service configuration element. So if you are deleting the provider pointed to by the jacc attribute then make sure the attribute value is also changed to the name of some other jacc-provider that exists under the security-service. Any change to the jacc attribute of a running service would require restart of the server.
--------

Comment by Scott Fordin [ 21/Mar/11 ]

Added topic to 3.1 Release Notes. Will make corrections to man pages for 3.2 release. Removing release notes tag.

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in the 3.1.1 bundled docs

Comment by Scott Fordin [ 31/May/11 ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 07/Jun/11 ]

Reassigned to the security writer

Comment by kevinmcd [ 15/Jun/11 ]

Text changed as indicated. I reworded it a little, and changed "jacc attribute" to "jacc-provider element." I will update the bug status when the revised manpages are available in the build.

Comment by kevinmcd [ 11/Jul/11 ]

Change appears in svn revision 47759, which I checked in the nightly build of 07-Jul-2011.





[GLASSFISH-16066] set-web-context-param, set-web-env-entry man pages: incorrect case for --ignoredescriptoritem option Created: 21/Feb/11  Updated: 19/Dec/16  Resolved: 30/Jun/11

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

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-release-note-added, 3_1-release-notes

 Description   

The case of the --ignoredescriptoritem option of the set-web-context-param and set-web-env-entry subcommands has been changed from camel case to all lowercase. However, the man pages for these subcommands have not been updated to reflect this change and still list the option as --ignoreDescriptorItem.



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

Reassigned to writer who will fix it in 3.2. As this issue is tagged for inclusion in the release notes, the issue need not be assigned to the release notes writer.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Added "3_1-release-note-added" tag.

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in the 3.1.1 bundled docs

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.





[GLASSFISH-16008] create-local-instance --config manual page information is incorrect Created: 16/Feb/11  Updated: 19/Dec/16  Resolved: 30/Jun/11

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

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

Tags: 3_1-exclude

 Description   

See the first JC-001 comment here: http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Cluster+Infrastructure+Documentation+Review

This comment has not been addressed in the create-local-instance manual page.

The current content is the following:
--config
Specifies the named configuration that the instance
references. The configuration must exist and must not be
named default-config or server-config. If the configura-
tion name specifies a standalone configuration, an error
occurs. Specifying the --config option creates a shared
instance.

The -config option and the --cluster option are mutu
ally exclusive. If both options are omitted, a stan-
dalone instance is created.

The sentence beginning, "If the configuration name specifies..." is incorrect and should be removed.

The following is a legal usage:

asadmin copy-config default-config mycfg
asadmin create-local-instance --config mycfg i1
asadmin create-local-instance --config mycfg i2

But the manual page as written says that this is an error.



 Comments   
Comment by Paul Davies [ 16/Feb/11 ]

Too late to fix for 3.1.

Comment JC-001 relates to standalone instances and was addressed correctly. This error relates to standalone configurations.

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in the 3.1.1 bundled docs

Comment by Paul Davies [ 14/Jun/11 ]

This issue affects the following manual pages:

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.





[GLASSFISH-16125] Launch link brings 404 error after installing an Add-On and before restart Created: 02/Mar/11  Updated: 19/Dec/16  Resolved: 15/Nov/11

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

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

Attachments: JPEG File launch-404error.JPG     Text File server.log    
Tags: 3_1_1-verified

 Description   

While verifying another bug, http://java.net/jira/browse/GLASSFISH-14310, I encountered an issue where launch link was bringing a 404 page. Steps to reproduce:

1. In Admin Console go to update tool and click on Available Add-Ons.
2. Choose an add-on and click Install.
3. Without restarting server go to an already deployed application and click on Launch link - 404 error is displayed instead of expected application's links. The url displayed in the browser is:

http://tuppy.us.oracle.com:4848/updateCenter/applications/webApplicationLinks.jsf?appID=hello&contextRoot=/hello

instead of the regular url when things work that's:

http://tuppy.us.oracle.com:4848/common/applications/webApplicationLinks.jsf?appID=hello&contextRoot=/hello

Restarting server clears this problem.



 Comments   
Comment by sirajg [ 25/Mar/11 ]

I cannot reproduce this problem. Did you use the back button?

Comment by sirajg [ 20/Apr/11 ]

Cannot reproduce using the instructions given in the bug report. Please reopen if the issue can still be reproduced.

Comment by lidiam [ 27/Jun/11 ]

Reopening to add verified tag.

Comment by lidiam [ 27/Jun/11 ]

Verified in build b08.

Comment by Anissa Lam [ 17/Oct/11 ]

reopen to mark the fix version field.

Comment by Anissa Lam [ 15/Nov/11 ]

change Resolution back to Fixed.





[GLASSFISH-16182] *-application-ref* man pages: Examples have deprecated syntax Created: 09/Mar/11  Updated: 19/Dec/16  Resolved: 21/Jun/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-16178 Umbrella bug. For several *ref comman... Resolved
Tags: 3_1-exclude

 Description   

Build 43.

The syntax in the examples in the man pages for create-application-ref, list-application-refs, and delete-application-ref is deprecated. These examples include the asadmin options --user and passwordfile in a multimode session after the subcommand:

asadmin> create-application-ref --user admin2
--passwordfile passwords.txt --target NewServer MyWebApp
Command create-application-ref executed successfully.
asadmin> list-application-refs --user admin2
--passwordfile passwords.txt NewServer
ClientSessionMDBApp
MEjbApp
__ejb_container_timer_app
Command list-application-refs executed successfully.
asadmin> delete-application-ref --user admin2
--passwordfile passwords.txt --target NewServer MyWebApp
Command delete-application-ref executed successfully.

When these examples are run, the asadmin utility displays a message that the syntax is deprecated.

To fix, delete the asadmin options from the examples.



 Comments   
Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in 3.1.1.

Comment by Rebecca Parks [ 21/Jun/11 ]

Removed --user and --passwordfile options from examples exactly as requested. Resolving issue.





[GLASSFISH-16183] *-resource-ref* man pages: Examples have deprecated syntax Created: 09/Mar/11  Updated: 19/Dec/16  Resolved: 30/Jun/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-16178 Umbrella bug. For several *ref comman... Resolved
Tags: 3_1-exclude

 Description   

Build 43.

The syntax in the examples in the man pages for create-resource-ref, list-resource-refs, and delete-resource-ref is deprecated. These examples include the asadmin options --user and passwordfile in a multimode session after the subcommand:

asadmin> create-resource-ref --user admin
--passwordfile passwords.txt --target Cluster1 jms/Topic
Command create-resource-ref executed successfully.
asadmin> list-resource-refs --user admin
--passwordfile passwords.txt
jms/Topic
Command list-resource-refs executed successfully.
asadmin> delete-resource-ref --user admin2
--passwordfile passwords.txt --target NewServer jms/Topic
Command delete-resource-ref executed successfully.

When these examples are run, the asadmin utility displays a message that the syntax is deprecated.

To fix, delete the asadmin options from the examples.



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

Will make fix in 3.2 man pages.

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in 3.1.1.

Comment by Scott Fordin [ 31/May/11 ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.





[GLASSFISH-16177] For: list-file-users, list-log-attributes, list-jacc-providers, list-jndi-resources --help wrongly describes: --target. Created: 08/Mar/11  Updated: 19/Dec/16  Resolved: 11/Jul/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1

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


 Description   

Build 43. Solaris 10 Sparc. Executed:

asadmin <commnd_name> --help for the follow commands:
list-file-users
list-log-attributes
list-jacc-providers
list-jndi-resources

For these commnds asadmin <commnd_name> --help returned an info that exists:

[--target target] option. But really the attempt to use --target returned such error message, for example:

asadmin list-jacc-providers --target c1
Invalid option: --target
Usage: asadmin [asadmin-utility-options] list-jacc-providers
[?|-help[=<help(default:false)>]] [target]
Command list-jacc-providers failed

Also for list-jndi-resources the command: asadmin list-jndi-resources -help returns: [targetoperand]. What does it mean? For all other commnds this is simple: [target].



 Comments   
Comment by kumarjayanti [ 08/Mar/11 ]

The usage string for list-file-users shows the following correct usage :

$ ./asadmin list-file-users -lX
Invalid option: l
Usage: asadmin [asadmin-utility-options] list-file-users
[--authrealmname <authrealmname>] [?|-help[=<help(default:false)>]]
[target]
Command list-file-users failed.

Comment by kumarjayanti [ 08/Mar/11 ]

same for list-jacc-providers

./asadmin list-jacc-providers -lx
Invalid option: l
Usage: asadmin [asadmin-utility-options] list-jacc-providers
[?|-help[=<help(default:false)>]] [target]
Command list-jacc-providers failed.

Comment by easarina [ 08/Mar/11 ]

For all these commnds the usage string gave a correct info, but --help gave wrong information.

Comment by Scott Fordin [ 15/Mar/11 ]

Will make fix to 3.2 man pages.

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in 3.1.1.

Comment by Scott Fordin [ 31/May/11 ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 07/Jun/11 ]

Reassigned to security writer. Kevin, as the fix is the same, please also fix the man pages affected that are not security related.

Comment by kevinmcd [ 22/Jun/11 ]

I removed the --target option usage and added target as an operand for the following man pages: list-file-users, list-log-attributes, and list-jacc-providers. (Paul Davies also changed list-jndi-resources as part of GLASSFISH-15875.)

However, I have a question about the allowable values for target. From testing these commands, it looks like all four of the commands allow these values:

server_name (The default value is server.)
instance_name
configuration_name
cluster_name

Is this correct?

Comment by kevinmcd [ 24/Jun/11 ]

Kumar answered/confirmed query via email, changes made as indicated. Will update status of the bug when updated manpage available in build.

Comment by kevinmcd [ 11/Jul/11 ]

Change appears in svn revision 47759, which I checked in the nightly build of 07-Jul-2011.





[GLASSFISH-15875] man-page-review : list-admin-objects, list-connector-resources, list-jndi-resources Created: 07/Feb/11  Updated: 19/Dec/16  Resolved: 30/Jun/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Tags: 3_1-exclude

 Description   

Raising this issue as part of man pages review process of docs :

http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Connectors+Documentation+Review

man-pages affected :
1) list-admin-objects
2) list-connector-resources
3) list-jndi-resources
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"target" is an "operand" and not an "option" and hence it should be described under the section "operand" in the above commands' man pages.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



 Comments   
Comment by Scott Fordin [ 11/Feb/11 ]

Completed edits to man pages and checked pages into doc workspace.

Comment by Jagadish [ 16/Feb/11 ]

I still see that "target" is listed in "options" section apart from the appropriate "operands" section.
This can be fixed for 3.2 as its too late for 3.1

Comment by Scott Fordin [ 17/Mar/11 ]

Will update man pages for 3.2.

Comment by Paul Davies [ 27/May/11 ]

Under consideration for fixing in the 3.1.1 bundled docs.

Comment by Scott Fordin [ 31/May/11 ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 30/Jun/11 ]

Fix committed in revision 47759.





[GLASSFISH-16097] [UB]create-domain --template documentation is insufficient Created: 24/Feb/11  Updated: 19/Dec/16  Resolved: 30/Jun/11

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

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

Attachments: HTML File create-domain-from-template.html    

 Description   

This request was sent to the as-tech alias:

Subject: need more details or documentation on domain template usage
From: gajanan <Gajanan.Kulkarni@sun.com>
Date: Thu, 24 Feb 2011 21:42:12 +0530
To: as-tech@sun.com

Hi,
need more details or documentation on domain template usage.
how this can be used, how this can be edited etc.
can user strip of some of the un required elements.
if this is documented in better way in V3.1 it would be good.

Thanks
Gajanan.

The create-domain manual page explains that the --template option can be used to select a different template, but there isn't any information about how to write a new template.

Maybe there should be a section in Chapter 3 of the Administration Guide to explain how to edit domain templates.



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

Fix in 3.2.

Comment by Paul Davies [ 30/Jun/11 ]

Fix is contained in the attached fiile and will be published in the next update of the documentation.





[GLASSFISH-16094] On Windows the first time pkg.bat or updatetool.bat is run they may echo garbage Created: 24/Feb/11  Updated: 19/Dec/16  Resolved: 15/Mar/11

Status: Resolved
Project: glassfish
Component/s: update_center
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1

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

Issue Links:
Dependency
depends on UPDATECENTER2-2176 Windows bootstub wrapper script has e... In Progress
Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes

 Description   

On Windows if you don't install the Update Center via the installer, the first time you run pkg.bat (or updatetool.bat) the scripts echo a bunch of stuff before prompting the user asking them if they would like to install the software. Things work, it's just ugly.



 Comments   
Comment by Joe Di Pol [ 24/Feb/11 ]

This is caused by a bad "@echo on" statement in the pkg.bat bootstrap wrapper script. One work-around is to remove the echo statement (immediately after the copyright block), but more likely is the users should just ignore the garbage.

This is covered by UC issue UPDATECENTER2-2176 and we may want to mention it in the GlassFish release notes.

Comment by Scott Fordin [ 15/Mar/11 ]

Added topic to 3.1 Release Notes. Will appear in next doc set refresh.

Comment by Joe Di Pol [ 26/Apr/11 ]

This will be fixed in the product when uc2.3.4-B53 is picked up, which is planned for GlassFish 3.1.1





[GLASSFISH-16089] WAB deployment for a JSF app broken Created: 23/Feb/11  Updated: 19/Dec/16  Resolved: 17/Oct/11

Status: Closed
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1

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

Attachments: File jsf-wab-test.war    

 Description   

From Ed's email :

I have a hudson job that builds the 3.1 branch from source every night [1].

Yesterday, I noticed that the WAB deployment for a JSF app stopped
working. I went back into my build history and found that WAB
deployment with the following nightly did work.

573 unzip /home/ejburns/Documents/JavaEE/workareas/glassfish-3_1X_ROLLING/distributions/glassfish/target-2011-02-04_11-34-16/glassfish.zip

Using the following command:

577 ./asadmin deploy --type osgi /home/ejburns/Documents/JavaEE/workareas/i_gf_15809/i_11636_reproducer/maven-module-that-makes-wab/target/Test1-0.0.2.war

I am able to see the expected messages in the log that the managed bean
was found and Mojarra was initialized.

However, when I do the same deployment command of the same WAB using
this build:

588 unzip /home/ejburns/Documents/JavaEE/workareas/glassfish-3_1X_ROLLING/distributions/glassfish/target-2011-02-23_05-23-43/glassfish.zip

I see no messages about the managed bean being found, nor do I see that
Mojarra gets initialized. The log file from the 20110223 build is
attached. Note that the version of Mojarra is the same in both of these
builds, 2.1.0-b11.

This seems like a big problem.

I'm in class all this week but my phone is forwarded and I'll take calls.

Ed

[1] http://adc2110030us.oracle.com:7070/hudson/job/GLASSFISH_3_1X_BRANCH/



 Comments   
Comment by Hong Zhang [ 23/Feb/11 ]

As this is WAB deployment, assign to sahoo for evaluation

Comment by Sanjeeb Sahoo [ 19/May/11 ]

Sheetal,

Is this still an issue? Can you attach the test WAB?

Sahoo

Comment by Sanjeeb Sahoo [ 19/May/11 ]

Reassigning to Sheetal to confirm if the bug exists. If so, how to reproduce.

Comment by rogerk [ 19/May/11 ]

ownsership

Comment by rogerk [ 19/May/11 ]

Attached. I don't think this is still an issue - I ran one of our unit tests - but please verify.

Comment by rogerk [ 31/May/11 ]

This appears to be working with our unit tests.

Comment by rogerk [ 17/Oct/11 ]

Fix Version

Comment by rogerk [ 17/Oct/11 ]

I believe this was fixed in 3.1.1.

Comment by rogerk [ 17/Oct/11 ]

Fix version.





[GLASSFISH-16007] JDBC Pools: Load Defaults does not load default values for resource type Created: 16/Feb/11  Updated: 19/Dec/16  Resolved: 17/Oct/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1, 4.0

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

promoted build b43


Attachments: JPEG File jdbcpool-update-error.JPG     Text File server.log    
Tags: 3_1-exclude, 3_1_1-approved, 3_1_1-scrubbed, 3_1_1-verified

 Description   

Steps to reproduce:

1. Go to JDBC Connection Pools and click on DerbyPool.
2. Modify Resource Type to e.g. java.sql.Driver, and enter some bogus Driver Classname. Note that Datasource Classname field got cleared. Save changes.
3. Go again to the DerbyPool and click on Load Defaults - Issue 1: default values for Resource Type and Datasource Classname are not brought back.
4. Change Resource Type back to javax.sql.DataSource and click Save. The following error is displayed:

An error has occurred
Check server log for more information.

Server log contains:

[#|2011-02-16T10:28:50.343-0800|SEVERE|oracle-glassfish3.1|org.glassfish
.admingui|_ThreadID=23;_ThreadName=Thread-1;|updateEntity failed. parent='http:
//localhost:4848/management/domain/resources/jdbc-connection-pool/DerbyPool'; at
trs ='

{idleTimeoutInSeconds=300, transactionIsolationLevel=, driverClassname=ouc h.now, steadyPoolSize=8, nonTransactionalConnections=null, maxPoolSize=32, descr iption=null, datasourceClassname=, name=DerbyPool, maxWaitTimeInMillis=60000, po olResizeQuantity=2, ping=null, resType=javax.sql.DataSource, isIsolationLevelGua ranteed=true}

'|#]

Issue 2: The above does not mention the reason why the Save/Update action failed. We need to communicate this to user.



 Comments   
Comment by Anissa Lam [ 18/May/11 ]

Would like to see this fix for 3.1.1.

Comment by sumasri [ 24/May/11 ]

1)Update was failing because of the absence of class name while saving the values. This can be resolved by adding a check from GUI side to verify the presence of class name before saving the pool values.
2)There is no default value for resource type. Hence, it is not loading the value after clicking on Load defaults button.

Comment by sumasri [ 24/May/11 ]

Why fix this issue in 3.1.1?
o If data source or driver class name is not present, update is failing.

Which is the targeted build of 3.1.1 for this fix?
o MS4

Do regression tests exist for this issue?
o No. Manual testing should be sufficient

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
o verify the bug reported is fixed

Diffs:

Index: jdbc/src/main/resources/jdbcConnectionPoolEditButtons.inc
===================================================================
— jdbc/src/main/resources/jdbcConnectionPoolEditButtons.inc (revision 47043)
+++ jdbc/src/main/resources/jdbcConnectionPoolEditButtons.inc (working copy)
@@ -45,7 +45,7 @@
<!facet pageButtonsTop>
<sun:panelGroup id="topButtons">
<sun:button id="saveButton" rendered="#

{edit}

" text="$resource

{i18n.button.Save}

"

  • onClick="if (guiValidate('# {reqMsg}','#{reqInt}','#{reqPort}')) {submitAndDisable(this, '$resource{i18n.button.Processing}');}; return false;" >
    + onClick="if (isClassNamePresent('$resource{i18njdbc.msg.Error.classNameCannotBeEmpty}') && guiValidate('#{reqMsg}

    ','#

    {reqInt}

    ','#

    {reqPort}

    '))

    Unknown macro: {submitAndDisable(this, '$resource{i18n.button.Processing}');}

    ; return false;" >
    <!command
    gf.updateEntity(endpoint="#

    {pageSession.resourceUrl}

    "
    attrs="#

    {pageSession.valueMap}

    "
    Index: jdbc/src/main/resources/jdbcConnectionPoolEdit.jsf
    ===================================================================

      • jdbc/src/main/resources/jdbcConnectionPoolEdit.jsf (revision 47043)
        +++ jdbc/src/main/resources/jdbcConnectionPoolEdit.jsf (working copy)
        @@ -140,14 +140,33 @@
        }
        function disableEnableFields(type) {
        if(type == 'java.sql.Driver')
        Unknown macro: {+ var val = document.getElementById("$pageSession{dsTextField}").value;
        disableComponent("$pageSession{dsTextField}", 'text');+ document.getElementById("$pageSession{dsTextField}").value = val;
        enableComponent("$pageSession{ddsTextField}", 'text');
        } else{
        enableComponent("$pageSession{dsTextField}", 'text');+ var val = document.getElementById("$pageSession{ddsTextField}").value;
        disableComponent("$pageSession{ddsTextField}", 'text');+ document.getElementById("$pageSession{ddsTextField}").value = val;
        }
        }

        + function isClassNamePresent(reqMsg) {
        + var resType = document.getElementById("$pageSession{resTypeVal}").value;
        + var className = '';
        + if (resType == 'java.sql.Driver') {
        + className = document.getElementById("$pageSession{ddsTextField}").value;+ }

        else

        Unknown macro: {+ className = document.getElementById("$pageSession{dsTextField}").value;+ }

        + if (className == null || className == '')

        { + showAlert(reqMsg); + return false; + }

        + return true;
        + }
        +
        </script>
        </f:verbatim>

Comment by scatari [ 24/May/11 ]

Approved for 3.1.1.

Comment by Anissa Lam [ 24/May/11 ]

Change looks good. Please check into both trunk & 3.1.1 branch.

Comment by sumasri [ 24/May/11 ]

checked in to both trunk and branch 3.1.1

Comment by shaline [ 24/Jun/11 ]

Verified on GF 3.1.1 nightly dated 06/24.

Comment by Anissa Lam [ 17/Oct/11 ]

re-open issue to add the 'fixed version' field.

Comment by Anissa Lam [ 17/Oct/11 ]

change back to closed status.





[GLASSFISH-16397] ResourceAllocationException occurred in "Edit JDBC Connection Pool Advanced Attributes" page. Created: 21/Apr/11  Updated: 19/Dec/16  Resolved: 22/Jun/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1.1, 4.0

Type: Bug Priority: Major
Reporter: li.wu Assignee: sumasri
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

OS: Solaris 10 x86
Bundles: java_ee_sdk-6u2-web-b43a-jdk-solaris-x86-ml.sh
Locale: it_IT.UTF-8


Attachments: JPEG File JDBCConnectionPool.jpg     JPEG File ResourceAllocationException.jpg    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-16893 Provide a dev test for JDBC Connectio... Sub-task Open sumasri  
Tags: 3_1_1-approved

 Description   

Click DerbyPool under JDBC Connection Pools in the left tree.
Switch to Advanced tab in the main frame, and ResourceAllocationException occurred. Pls check picture attached.

The same issue occurs on Win7 x63 with the bundle of java_ee_sdk-6u2-web-b43a-jdk-windows-x64-ml.exe, and the locale is en_US.UTF-8.



 Comments   
Comment by scatari [ 17/May/11 ]

Approved for 3.1.1.

Comment by sumasri [ 24/May/11 ]

Checked in the change in both trunk and branch 3.1.1.
Will add a dev test for this change and close the issue..

Comment by sumasri [ 22/Jun/11 ]

As the code is checked in, Closing the issue as resolved.

Comment by sumasri [ 22/Jun/11 ]

By mistake, Closed the issue instead of resolved status..

Comment by sumasri [ 22/Jun/11 ]

Status to Resolved

Comment by Anissa Lam [ 17/Oct/11 ]

issues fixed for 4.0 (trunk) and 3.1.1





[GLASSFISH-16831] DAS General page should inform user whether secure admin is turned on or not Created: 09/Jun/11  Updated: 21/Sep/15  Resolved: 21/Sep/15

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

Type: New Feature Priority: Major
Reporter: Anissa Lam Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-scrubbed, 3_1_next

 Description   

During the handoff this, it is requested that GUI should show user whether secure admin has been turned or not. Otherwise, user needs to click the "Secure Administration..." button to find out the status. (Although the url is using https and should indicate that already).

The screen should add

Secure Administration : Enabled (or Not Enabled)

to the screen above the Debug information line.



 Comments   
Comment by srinik76 [ 10/Jun/11 ]

Why fix this issue in 3.1.1?
More usability. User will b able to know if server is secure admin enable/disabled just by seeing the home page

Which is the targeted build of 3.1.1 for this fix?
3.1.1_b08

Do regression tests exist for this issue?
Dev tests will be added

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

Comment by scatari [ 10/Jun/11 ]

Approved for 3.1.1.

Comment by srinik76 [ 15/Jun/11 ]

Will be done in future release and not in 3.1.1

Comment by Anissa Lam [ 15/Jun/11 ]

This is related to a new feature for 3.2

Comment by srinik76 [ 17/Jun/11 ]

Checked into the v3 trunk workspace.

Sending src/main/resources/appServer/serverInstGeneralPe.jsf
Transmitting file data .
Committed revision 47540.

Comment by srinik76 [ 17/Jun/11 ]

Closing the issue





[GLASSFISH-20940] create-file-user password option for --passwordfile isn't documented on Glassfish 4 Created: 23/Dec/13  Updated: 23/Dec/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1.1

Type: Bug Priority: Major
Reporter: atrajano Assignee: kevinmcd
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

To pass in the password for a user to the create-file-user command, the method is to use the --passwordfile option with the following variable:

AS_ADMIN_USERPASSWORD=mypassword

This isn't documented in the manual page for create-file-user, specifically, that the name of the variable in the password file is AS_ADMIN_USERPASSWORD.

This bug was prompted by issue GLASSFISH-16277 which is related to using create-file-user in embedded mode. However, this documentation fix is intended to deal with the CLI case. For the embedded case, once 16277 is resolved, then the embedded documentation needs to be updated with an explanation of how to pass a password to an embedded command.



 Comments   
Comment by atrajano [ 23/Dec/13 ]

help create-file-user on asadmin does not talk about the --passwordfile option

SYNOPSIS
create-file-user [--help] [--authrealmnameauth_realm_name]
[--target target
[--groups user_groups[:user_groups]*] user_name





[GLASSFISH-11717] Embedded EJB fail with MDB present Created: 23/Mar/10  Updated: 23/Mar/12  Resolved: 23/Mar/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: V3
Fix Version/s: 3.1.1

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

Operating System: All
Platform: Sun


Issuezilla Id: 11,717
Tags: 3_1-exclude

 Description   

If an MDB is present in the EJB module, the module fails to be loaded with
various exceptions:

(1) http://forums.java.net/jive/thread.jspa?messageID=392399

(2) [java] SEVERE: MQJMSRA_RA4001: start:Aborting:JMSException on
createConnection=[C4003]: Error occurred on connection creation
[localhost:7676]. - cause: java.net.ConnectException: Connection refused
[java] com.sun.messaging.jms.JMSException: [C4003]: Error occurred on
connection creation [localhost:7676]. - cause: java.net.ConnectException:
Connection refused
[java] at com.sun.messaging.jmq.jmsclient.ExceptionHandler.throw



 Comments   
Comment by marina vatkina [ 26/Mar/10 ]

work in progress

Comment by marina vatkina [ 13/May/10 ]

Please assign back to me and ejb-container when SJSMQ ra starts in EMBEDDED mode
in embedded GlassFish run.

Comment by Satish Kumar [ 05/Oct/10 ]

MQ binaries need to be added to the embedded jar for the broker to function in
embedded GF

Re-assiging this to Bhavani to add the MQ binaries into embedded GF jar...

Comment by Bhavanishankar [ 10/Oct/10 ]

Added keyword.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by marina vatkina [ 23/Mar/12 ]

MDBs can be tested with Embeddable EJB container, but resources should be predefined. There is no way to exclude MDBs from loading.





[GLASSFISH-4240] [online docs] Connector security map - incorrect reference to CMT Created: 21/Feb/08  Updated: 10/Jan/12  Resolved: 10/Jan/12

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: v2.1
Fix Version/s: 3.1.1

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

Operating System: All
Platform: All
URL: http://java.sun.com/javaee/5/docs/tutorial/doc/bncal.html


Issuezilla Id: 4,240
Status Whiteboard:

as911-na


 Description   

In multiple places, CLI man pages, admin pages, Java EE 5 tutorial etc (both
GlassFish and Sun application server doc bundles), we refer to Container managed
transaction, when we should have actually said container managed authentication
or container managed sign-on, while describing Connector security maps.

For example in CLI man page for create-connector-security-map
"Use this command to create a security map for the specified
connector connection pool. If the security map is not present, a new
one is created. Also, use this command to map the caller identity of
the application (principal or user group) to a suitable EIS principal
in container-managed transaction-based scenarios."

and also in
http://java.sun.com/javaee/5/docs/tutorial/doc/bncal.html
http://docs.sun.com/app/docs/doc/819-4736/6n6s9pj1p?l=en&a=view&q=create-connector-security-map
http://docs.sun.com/app/docs/doc/819-3675/6n5slue7h?l=en&a=view&q=create-connector-security-map

Please correct all the docs that incorrectly make this statement and feel free
to create sub-issues if an issue needs to be raised for each document.



 Comments   
Comment by Paul Davies [ 20/Mar/08 ]

Reassigned to AS 9.1.1 doc lead

Comment by harpreet [ 25/Mar/08 ]

Approving for v2.1

Comment by cs194067 [ 01/Jul/08 ]

reassigning to chinmayee

Comment by cs194067 [ 01/Jul/08 ]

Needs to be fixed in v2.1 docs

Comment by harpreet [ 16/Oct/08 ]

Not a critical issue for v2.1 - removing it from the approved list.

Comment by chinmayee_srivathsa [ 16/Oct/08 ]

Will fix in all unbundled docs.

Comment by chinmayee_srivathsa [ 30/Oct/08 ]

Changing the priority to P3 because this is not seen as a critical issue for v2.1.

Fixed in the man pages (yet to be integrated with the build, will update this
issue when that is done).
Will also fix in the online docs.

Comment by cs194067 [ 06/Nov/08 ]

Fixed in the man page.

Need to fix in the online docs.

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Paul Davies [ 26/May/11 ]

Mike, please determine if this issue still applies. If so, please fix for 3.1.1. If not, please resolve or close.

Comment by Mike Fitch [ 19/Jul/11 ]

Changed "container-managed transaction" to "container-managed authentication" in the create-connector-security-map man page and in the GlassFish Administration Guide.

Comment by Mike Fitch [ 10/Jan/12 ]

This was fixed in 3.1.1.





[GLASSFISH-16430] Embedded GlassFish should have fidelity with regular GlassFish. Created: 21/Apr/11  Updated: 22/Dec/11  Resolved: 22/Dec/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 4.0
Fix Version/s: 3.1.1, 3.1.2, 4.0

Type: New Feature Priority: Major
Reporter: Bhavanishankar Assignee: Bhavanishankar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ALL


Issue Links:
Dependency
depends on GLASSFISH-16493 Unable to deploy an application conta... Resolved
depends on GLASSFISH-16546 iiop-listener keeps running even afte... Resolved

 Description   

The GlassFish embedded inside user's application using org.glassfish.embeddable APIs should have fidelity with the regular GlassFish.

This does NOT mean the running mode should be same (OSGi or non-OSGi). But it means that the functionality of the GlassFish must be same in terms of being able to run all Java EE applications as is.



 Comments   
Comment by Bhavanishankar [ 21/Apr/11 ]

In 3.1, there is already some degree of fidelity in the web technology areas.

In 3.2, the uncovered areas of full Java EE profile should also be covered.

Comment by Bhavanishankar [ 30/May/11 ]

Unable to run full profile CTS tests without having a fix for GLASSFISH-16546.

Comment by Bhavanishankar [ 11/Aug/11 ]

This is resolved in 3.1.1.

Comment by shreedhar_ganapathy [ 01/Sep/11 ]

Which build of 3.1.1 has this issue's resolution? Could you update the fix version to right release and build number? If this has been fixed in 3.1.2 branch, please use the 3.1.2_<buildnumber> fixVersion.

Comment by Bhavanishankar [ 22/Dec/11 ]

Final build of 3.1.1 and all 3.1.2 builds would have this fix. Marking it resolved.





[GLASSFISH-10638] monitoring: some statistics missing under http-service node Created: 28/Oct/09  Updated: 02/Dec/11  Resolved: 21/Apr/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: V3
Fix Version/s: 3.1.1, 3.1.2, 4.0

Type: Bug Priority: Major
Reporter: Jennifer Chou Assignee: Amy Roh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-4344 Monitoring support Web container in V3 Resolved
Issuezilla Id: 10,638
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude

 Description   

I tried to map out the tree hierarchy for the http-service statistics under the
server.http-service node using data from REST, CLI, and the v2 stats listed in
the monitoring dashboard. I marked the ones that are new in v3 and the ones
that were in v2 but not in v3.

These statistics seem to be missing in v3. They were available in v2.

  • id
  • interfaces
  • mode
  • countbytesreceived
  • countbytestransmitted
  • countopenconnections
  • countrequests
  • maxbytetransmissionrate
  • maxopenconnections
  • method
  • ratebytestransmitted
  • uri

Tree hierarchy:

server
--> http-service
--> __asadmin

  • state (new in v3)
  • hosts
  • id (in v2, missing in v3)
  • interfaces (in v2, missing in v3)
  • mode (in v2, missing in v3)
    --> request
  • count404
  • count302
  • count3xx
  • count304
  • processingtime (new in v3)
  • count503
  • count2xx
  • count400
  • errorcount (new in v3)
  • count403
  • requestcount (new in v3)
  • count5xx
  • count401
  • count200
  • countother
  • count4xx
  • maxtime (new in v3)
  • countbytesreceived (in v2, missing in v3)
  • countbytestransmitted (in v2, missing in v3)
  • countopenconnections (in v2, missing in v3)
  • countrequests (in v2, missing in v3)
  • maxbytetransmissionrate (in v2, missing in v3)
  • maxopenconnections (in v2, missing in v3)
  • method (in v2, missing in v3)
  • ratebytestransmitted (in v2, missing in v3)
  • uri (in v2, missing in v3)


 Comments   
Comment by oleksiys [ 12/Nov/09 ]

change target milestone

Comment by oleksiys [ 11/Oct/10 ]

target for ms7

Comment by oleksiys [ 12/Nov/10 ]

Grizzly doesn't expose stats for virtual servers.
reassign to webcontainer for investigation.

Comment by Amy Roh [ 16/Nov/10 ]

Can you include the steps to view the virtual server statistics? The following
commands only return server.network.*

asadmin set
configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=HIGH
asadmin get -m server.*

Comment by Amy Roh [ 21/Apr/11 ]

These missing stats in v3 were added. Fixed in svn 45015 & 45048.

id
mode
countbytesreceived
countbytestransmitted
countopenconnections
countrequests
maxbytetransmissionrate
maxopenconnections
method
ratebytestransmitted
uri





[GLASSFISH-16938] Glassfish embedded runs JMSRA broker in REMOTE mode regardless of settings Created: 01/Jul/11  Updated: 02/Dec/11  Resolved: 05/Jul/11

Status: Closed
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1
Fix Version/s: 3.1.1, 4.0

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

all platforms


Attachments: Text File run.log    

 Description   

I wrote an unit test which runs an embedded glassfish server and deploy my application on it:

String glassfishHome = "src/test/glassfish";
String instanceRoot = glassfishHome + "/domains/some-domain";
String configFile = instanceRoot + "/config/domain.xml";

Map<String, String> props = new HashMap<String, String>();
props.put("org.glassfish.ejb.embedded.glassfish.installation.root", installRoot);
props.put("org.glassfish.ejb.embedded.glassfish.instance.root", instanceRoot);
props.put("org.glassfish.ejb.embedded.glassfish.configuration.file", configFile);
props.put(EJBContainer.APP_NAME, "appName");

ejbContainer = EJBContainer.createEJBContainer(props);

The domain.xml file contains (among others) the following configuration:

<jms-service default-jms-host="default_JMS_host" type="EMBEDDED">
  <jms-host host="localhost" name="default_JMS_host"></jms-host>
</jms-service>

Everything is OK until my application contains MDB beans. In such situation JMSRA broker is run but in REMOTE mode, what can be seen in logs:

 
2011-07-01 12:07:53 com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter: Version:  4.5  (Build 29-b) Compile:  Wed Feb  9 22:53:30 PST 2011
2011-07-01 12:07:53 com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter starting: broker is REMOTE, connection mode is TCP
2011-07-01 12:07:53 com.sun.messaging.jms.ra.ResourceAdapter start
INFO: MQJMSRA_RA1101: GlassFish MQ JMS Resource Adapter Started:REMOTE

Because of this mode my MDB beans cannot connect to this remote broker and deployment of the application fails!

When the same domain.xml file is used in a standalone glassfish installation my application works. JMSRA is run in the propper mode: EMBEDDED.

Why a glassfish embedded server runs JMSRA broker in REMOTE mode regardless of the setting?



 Comments   
Comment by Satish Kumar [ 05/Jul/11 ]

We have tried to reproduce this using org.glassfish.embeddable API. Here, MQ is starting correctly in EMBEDDED mode, as specified in the custom domain.xml.

Attached is the client code from our test run (it uses mdb.war from v3/tests/embedded/maven-plugin). The log file from our test run is attached to this issue.

-----------------Test.java

import org.glassfish.embeddable.*;
import java.io.*;
public class Test {

public static void main(String... args) throws Exception

{ BootstrapProperties p1 = new BootstrapProperties(); p1.setInstallRoot(System.getenv("S1AS_HOME")); GlassFishRuntime gfr = GlassFishRuntime.bootstrap(p1); GlassFishProperties p2 = new GlassFishProperties(); p2.setInstanceRoot(System.getenv("S1AS_HOME") + "/domains/domain1"); p2.setConfigFileURI("file://" + System.getenv("S1AS_HOME") + "/domains/domain1/config/domain.xml"); GlassFish gf = gfr.newGlassFish(p2); gf.start(); gf.getCommandRunner().run("create-jms-resource", "--restype=javax.jms.Queue", "--property=imqDestinationName=TestQueue", "jms/TestQueue"); gf.getCommandRunner().run("create-jms-resource", "--restype=javax.jms.QueueConnectionFactory", "jms/TestQueueConnectionFactory"); String appName = gf.getDeployer().deploy(new File("mdb.war")); gf.dispose(); }

}
---------------------

This issue appears to be specific to the embedded EJB container. Looks like EJBContainer.createContainer is always forcing MQ to start in REMOTE mode. Hence, assigning to Marina...

Comment by Satish Kumar [ 05/Jul/11 ]

Changing component from JMS to ejb container

Comment by marina vatkina [ 05/Jul/11 ]

While the fix was made on JMS side, I won't reasign the bug back. In 3.1 MDBs were not supported in embeddable EJB container.





[GLASSFISH-10078] Chatty Kathy Startup Created: 07/Oct/09  Updated: 02/Dec/11  Resolved: 03/Jun/11

Status: Resolved
Project: glassfish
Component/s: other
Affects Version/s: V3
Fix Version/s: 3.1.1, 4.0

Type: Bug Priority: Minor
Reporter: Byron Nevins Assignee: Richard S. Hall
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,078
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude

 Description   

I get junk at the end of the startup (see end of this description)
But I do NOT get a message like:

"GlassFish has successfully started blah blah blah."

I have just learned that the below line should be mentally translated to the
above line.

"INFO: felix.fileinstall.bundles.new.start true"

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

INFO: [Thread[GlassFish Kernel Main Thread,5,main]] started
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.poll (ms) 5000
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.dir
C:\glassfishv3\glassfish\domains\domain1\autodeploy\bundles
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.debug 1
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.bundles.new.start true
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.poll (ms) 5000
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.dir C:\glassfishv3\glassfish\modules\autostart
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.debug 1
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.bundles.new.start true
Oct 7, 2009 11:27:05 AM
INFO: Updating configuration from
org.apache.felix.fileinstall-autodeploy-bundles.cfg
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.poll (ms) 5000
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.dir
C:\glassfishv3\glassfish\domains\domain1\autodeploy\bundles
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.debug 1
Oct 7, 2009 11:27:05 AM
INFO: felix.fileinstall.bundles.new.start true



 Comments   
Comment by kumara [ 12/Oct/09 ]

Assign to Richard to determine whether it is a felix issue or the way felix is used in GlassFish. It is okay to
print one line for each module that is loaded but multiple lines make it un-readable.

Comment by Richard S. Hall [ 26/Oct/09 ]

This is not a framework issue, it is a File Install issue. I think Sahoo raised
the issue of File Install verbosity on the Felix developer mailing list, but I
am not sure of the status so I will have to check.

Comment by Richard S. Hall [ 27/Oct/09 ]

Sahoo says that File Install 2.0.4 might resolve this issue, but we need to test
it with GF to make sure there are no issues.

Comment by Richard S. Hall [ 06/Nov/09 ]

I integrated File Install 2.0.4...its startup output is definitely condensed,
but not necessarily significantly reduced.

I performed some tests with this version of File Install and it appeared to be
working for me. If Sahoo could take a closer look, that would be great.

Comment by kumara [ 16/Nov/09 ]

Well, I reviewed the new message and the message from file install is not upto the mark. For majority of
GlassFish users it is hard to understand noise in the log file.

I remember some discussion on GlassFish dev list about adding a filter and another one about creating a
OSGi logging service which is configure to not print the message. Can you please summarize the available
options, so we can make a decision on how to move forward?

Comment by Richard S. Hall [ 17/Nov/09 ]

There is an issue for this in Felix here:

https://issues.apache.org/jira/browse/FELIX-1789

I think we have two viable options to address this:

1. Install an OSGi Log Service impl, so File Install will use that rather than
stdout.
2. Patch and release a private version of File Install with a new configuration
property to control its verbosity.

I would recommend (2), since doing (1) this late in the game just to control
another module's verbosity seems heavy handed.

I will look into a patch for File Install.

Comment by Richard S. Hall [ 17/Nov/09 ]

If we want to create our own private release, then I propose this patch to File
Install:

Index: src/main/java/org/apache/felix/fileinstall/internal/Util.java
===================================================================
— src/main/java/org/apache/felix/fileinstall/internal/Util.java (revision 834974)
+++ src/main/java/org/apache/felix/fileinstall/internal/Util.java (working copy)
@@ -218,10 +218,13 @@
}
public void log(boolean debug, String message, Throwable throwable)
{

  • System.out.println(message + (throwable == null ? "" : ": " +
    throwable));
  • if (debug && throwable != null)
    + if (debug || (throwable != null))
    {
  • throwable.printStackTrace(System.out);
    + System.out.println(message + (throwable == null ? "" : ": " +
    throwable));
    + if (debug && throwable != null)
    + { + throwable.printStackTrace(System.out); + }

    }
    }
    }

This is quite simple, it leverages an existing configuration property to
determine the log level. If "debug" is NOT set, then it will only print out
messages if there is an exception associated with it (but it will not print the
exception stack trace). If "debug" is set, then it will print the message even
if there is no exception and will print the exception stack trace if there is one.

This is a hack, but at least it is simple. I won't commit this hack to the File
Install trunk, but will propose an improved approach. Still, I think this patch
could deal with our issue for now.

Thoughts?

Comment by Byron Nevins [ 17/Nov/09 ]

THere are TWO parts to this bug. Only part #1 is getting addressed so far

Part 1: Felix is too noisy

Part 2: V3 never logs a message saying "I have started and am ready to get busy!"
I.e. you haven no way to know when V3 is REALLY up and ready – other than
patiently waiting for all messages to stop for a while and then ASSUMING that
all went to plan.

Comment by Richard S. Hall [ 18/Nov/09 ]

Yes, I am only addressing Part 1.

And Part 1 is actually, "File Install is too noisy"...Felix Framework and Felix
File Install are different projects.

Comment by dochez [ 19/Nov/09 ]

this is unfortunate noise but we have no time to integrate a new file install binary

Comment by kumara [ 07/Dec/09 ]

Setting target release for unresolved issues submitted on v3 release to the next release. Not changing
issues submitted on v2.x release because they might not apply to v3.next release.

Comment by Richard S. Hall [ 07/Oct/10 ]

I think this issue was addressed in File Install, which now allows you to set a
log level per watched directory.

Comment by Nazrul [ 07/Oct/10 ]

I don't see the original reported messages in 3.1.

I saw the following messages that you may want to take a look:

[#|2010-09-07T10:55:55.102-0700|INFO|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Installed
/Users/nazrul/sep-7/glassfishv3/glassfish/modules/autostart/org.apache.felix.bundlerepository.jar|#]

[#|2010-09-07T10:55:55.248-0700|INFO|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Installed
/Users/nazrul/sep-7/glassfishv3/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg|#]

[#|2010-09-07T10:55:55.321-0700|INFO|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Installed
/Users/nazrul/sep-7/glassfishv3/glassfish/modules/autostart/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg|#]

[#|2010-09-07T10:55:55.361-0700|INFO|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Installed
/Users/nazrul/sep-7/glassfishv3/glassfish/modules/autostart/org.apache.felix.scr.jar|#]

[#|2010-09-07T10:55:56.446-0700|INFO|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Started
bundle:
file:/Users/nazrul/sep-7/glassfishv3/glassfish/modules/autostart/org.apache.felix.bundlerepository.jar|#]

Comment by Richard S. Hall [ 07/Oct/10 ]

I think the
osgi-platforms/felix/src/main/resources/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg
file needs to be edited to set a lower log level. You can test this in your
local install by editing it in the modules/autostart/ directory. Just set it to
the level you prefer.

Comment by Sanjeeb Sahoo [ 13/Oct/10 ]

I see three kinds of messages:
a) messages like .../autostart/...

They are now fixed with my following check-in:
ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -m "Issue #10078: Change
fileinstall log level to WARNING" packager/nucleus-base/lib/templates/domain.xml
Sending packager/nucleus-base/lib/templates/domain.xml
Transmitting file data .
Committed revision 41698.

b) messages like "DEBUG: Event Admin..."
This needs to be fixed in a third-party bundle. I have filed the following bug
against them:
https://issues.apache.org/jira/browse/FELIX-2655
When it is fixed, we shall integrate the same in GF.

c) message related to non-existent autodeploy/bundles/:
[#|2010-10-14T00:09:03.293+0530|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=Configuration
Updater;|/space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/domains/domain1/autodeploy/bundles
does not exist, please create it.|#]

I am going to fix this as part of this bug by creating the dir.

Comment by Sanjeeb Sahoo [ 13/Oct/10 ]

Fixing point #c mentioned in my previous comment:
ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -m "Issue #10078: Create
autodeploy/bundles/ dir as part of domain creation."
admin/server-mgmt/src/main/java/com/sun/enterprise/admin/servermgmt/pe/PEFileLayout.java
Sending
admin/server-mgmt/src/main/java/com/sun/enterprise/admin/servermgmt/pe/PEFileLayout.java
Transmitting file data .
Committed revision 41711.

Comment by Sanjeeb Sahoo [ 06/Nov/10 ]
      • Issue 14450 has been marked as a duplicate of this issue. ***
Comment by Sanjeeb Sahoo [ 18/Nov/10 ]

Messages like "Started ...Extender" is now logged in FINE level:
ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -m "Issue #10078: Log debug
messages at FINE level" osgi-javaee/
Sending
osgi-javaee/osgi-javaee-base/src/main/java/org/glassfish/osgijavaeebase/ExtenderManager.java
Transmitting file data .
Committed revision 42959.

Comment by Nazrul [ 29/Nov/10 ]

On the latest GlassFish 3.1 build, the following log messages showed up during start-up. Please change the log level for these:

[#|2010-11-29T17:45:05.191-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|ThreadID=17;_ThreadName=Thread-1;|___________________________
Welcome to Apache Felix Gogo

#]

[#|2010-11-29T17:45:10.471-0800|INFO|glassfish3.1|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-1;| JPAExtender started|#]

[#|2010-11-29T17:45:11.522-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|DEBUG: EventAdmin: org.apache.felix.eventadmin.CacheSize=30|#]

[#|2010-11-29T17:45:11.523-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|DEBUG: EventAdmin: org.apache.felix.eventadmin.ThreadPoolSize=20|#]

[#|2010-11-29T17:45:11.523-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|DEBUG: EventAdmin: org.apache.felix.eventadmin.Timeout=5000|#]

[#|2010-11-29T17:45:11.523-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|DEBUG: EventAdmin: org.apache.felix.eventadmin.RequireTopic=true|#]

[#|2010-11-29T17:45:11.577-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|DEBUG: EventAdmin: org.apache.felix.eventadmin.CacheSize=30|#]

[#|2010-11-29T17:45:11.577-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|DEBUG: EventAdmin: org.apache.felix.eventadmin.ThreadPoolSize=20|#]

[#|2010-11-29T17:45:11.577-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|DEBUG: EventAdmin: org.apache.felix.eventadmin.Timeout=5000|#]

[#|2010-11-29T17:45:11.578-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|DEBUG: EventAdmin: org.apache.felix.eventadmin.RequireTopic=true|#]

Comment by Sanjeeb Sahoo [ 05/Dec/10 ]

ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -m "Integrate eventadmin 1.2.8 to address issue GLASSFISH-10078" pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 43475.

With this only Gogo shell message that comes, but we won't fix that in this rel.

Comment by Nazrul [ 16/Dec/10 ]

We should get rid of the Felix Gogo shell message.

[#|2010-12-16T17:46:00.517-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|ThreadID=17;_ThreadName=Thread1;|___________________________
Welcome to Apache Felix Gogo

#]
Comment by Sanjeeb Sahoo [ 16/Dec/10 ]

Is this really important for 3.1? If so, justify. The cost of fixing is high as it requires a new release of gogo shell.

Comment by Sanjeeb Sahoo [ 16/Dec/10 ]

Will do in 3.2.

Comment by Richard S. Hall [ 03/Jun/11 ]

As far as I know, this is fixed in 3.1.





[GLASSFISH-16864] change-admin-password does not accept password file option Created: 15/Jun/11  Updated: 02/Dec/11  Resolved: 17/Jun/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: 3.1.1, 4.0

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

Windows


Tags: 3_1_1-approved

 Description   

Hello,

The following command is accepted when using the embedded API:
change-admin-password --passwordfile=xxx admin

with a password file containing

AS_ADMIN_PASSWORD=ABC
AS_ADMIN_NEWPASSWORD=XYZ

Invoking the same command with asadmin CLI does not work.
It complains that the change-admin-password does not take any operand.
The variant "change-admin-password --passwordfile=C:
pwd.txt --user=admin" prints the following output:
"Deprecated syntax, instead use: asadmin --passwordfile C:\pwd.txt --user admin change-admin-password [options]"
The suggested variant prompts for the password instead of taking them from password file.
This makes it impossible to invoke the change-admin-password non-interactively (except with embedded API).

Remark: if the output of the command (about deprecated syntax) is correct then the new syntax is not consistent with other commands like change-master-password or create-file-user which accepts the --passwordfile option. The "deprecated" syntax is more user friendly.

Thanks for your help.



 Comments   
Comment by Tom Mueller [ 16/Jun/11 ]

The root cause of this problem is that when running in embedded mode, the remote change-admin-password command, defined in the security/core module in the ChangeAdminPassword class is used. However, when running the command from asadmin, the local change-admin-password command, defined in the admin/cli module in the ChangeAdminPasswordCommand class is used. The latter calls the former.

The local command does not read passwords from the file passed by the --passwordfile option. It just reads them directly from the console.

Comment by Tom Mueller [ 17/Jun/11 ]

Fixed in the trunk with revision 47562.

With this fix, the usage is as follows for scripting the change-admin-password command.

Assuming the file "pw.txt" has the following contents:

AS_ADMIN_PASSWORD=admin123
AS_ADMIN_NEWPASSWORD=admin456

and the current admin password is "admin123", the the following command will change the password to admin456

asadmin --passwordfile pw.txt --user admin change-admin-password

Note that it is necessary to provide the username of the admin user to be changed using the --user option to asadmin. If this is not provided, the change-admin-password command will prompt for it.

Usage of the command when not using the --passwordfile option is unchanged.

As with any command that uses the -passwordfile option, if the filename is "", then the password file is read from the standard input. This allows scripts to change the admin password without ever writing the passwords to disk.

Comment by nlecroar [ 21/Jun/11 ]

Thanks for the support.
Will that fix be included in 3.1.1?

Comment by Tom Mueller [ 21/Jun/11 ]

Why fix this issue in 3.1.1?
The reporter of this bug expressed an interest in having it fixed in 3.1.1

Which is the targeted build of 3.1.1 for this fix?
build 9.

Do regression tests exist for this issue?
No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Test that involve the change-admin-password command.

Comment by scatari [ 21/Jun/11 ]

Approved for 3.1.1.

Comment by Tom Mueller [ 21/Jun/11 ]

Fixed on the 3.1.1 branch in revision 47602.





[GLASSFISH-16347] Glassfish 3.1 is much slower to deploy when many methods have RolesAllowed Annotations Created: 12/Apr/11  Updated: 15/Nov/11  Resolved: 04/Jul/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1.1
Fix Version/s: 3.1.1

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

Linux Redhat EL5 64 bit Jdk 1.6 update 24


Attachments: File granted.policy_v2     File granted.policy_v3     HTML File Hot_Spots_without_sec_ann.html     HTML File Hot_Spots_with_sec_ann.html    
Tags: 3_1-next, 3_1_1-approved

 Description   

Glassfish 3.1 is much slower to deploy when many methods have RolesAllowed Annotations
Our application previously deployed OK on glassfish 2.1 ( less than 1 minute )
Now on 3.1 it takes about 500 000 milliseconds which makes for a painfully slow development cycle.

I have experimented and what takes long is our Stateless Sesion Bean which is a Session Facade.
It is large with over 700 methods.

If I leave this out and just load a few ancillary stateless session beans our message beans, JPA classes etc the application deploys in about 20 s.

I made a test case with 800 methods called hello_000 to hello_800 and it deployed quickly.

each looked like

public String hello_000()
{
return "hello";
}

I then added @RolesAllowed on about a third of the methods and this is what caused the slowdown
it went from 20 000 millseconds to 180 000 milliseconds.

eg at top of class

@DeclareRoles(

{"Role1", "Role2", "Role3", "Role4", "Role5", "Role6"})
@RolesAllowed( {"Role1", "Role2", "Role3", "Role4", "Role5", "Role6"}

)
@Stateless
public class TestStateless implements TestStatelessRemote
{

Now some methods look like

@RolesAllowed(

{"Role1", "Role2" }

)
public String hello_001()
{
return "hello";
}

But it seems that the roles processing is the slow part.

See fourm discussion http://www.java.net/forum/topic/glassfish/glassfish/glassfish-31-much-slower-deploy



 Comments   
Comment by Nazrul [ 20/Apr/11 ]

This should be fixed in 3.1.1

Comment by Nithya Ramakrishnan [ 26/Apr/11 ]

From the instrumentation data obtained by profiling a test app (with and without security annotations mentioned in the test case, ) it appears that the increase in time is due to the deployment class MethodDescriptor (init and getParamterClassNamesFor).
While these methods take approximately 850 microseconds in the case without the annotations, they take about 130 milliseconds in the case with annotations (for an app with about 20 methods with overriding RolesAllowed annotations) .
Transferring to the deployment team for further analysis.

Comment by Nithya Ramakrishnan [ 26/Apr/11 ]

Attaching the Hotspots data

Comment by Nithya Ramakrishnan [ 26/Apr/11 ]

Transferring the issue to the deployment team for further analysis.

Comment by Hong Zhang [ 26/Apr/11 ]

Most of changes in the MethodDescriptor in 3.* are from ejb container, assign to ejb team to follow up on this.

Comment by Cheng Fang [ 09/May/11 ]

I'm in the process identifying a few hot spots. Can you attach your test app that has 700 business methods with @RolesAllowed?

Comment by james100 [ 10/May/11 ]

My development system is not internet connected so I cant send you the test case.
Should be a simple matter to create using the code above and a good editor.

Comment by Cheng Fang [ 11/May/11 ]

OK, I created a similar test bean with 700 business methods having @RolesAllowed. There are also class-level @DeclearRoles and @RolesAllowed annotations. I have identified some areas of improvement and will solidify them in the next few days.

Comment by Cheng Fang [ 19/May/11 ]

For the same test app (700-method bean), v2 generates a much smaller full descriptor, ejb-jar.xml. It contains role declaration elements and role linking elements, but no <method-permission> elements.

In v3, a complete list of <method-permission> elements are generated. That's about 792 <method-permission> elements in my test app:

<method-permission>
<role-name>Role1</role-name>
<method>
<ejb-name>TestBean</ejb-name>
<method-intf>Local</method-intf>
<method-name>sayHello617</method-name>
<method-params/>
</method>
<method>
<ejb-name>TestBean</ejb-name>
<method-intf>Local</method-intf>
<method-name>sayHello321</method-name>
<method-params/>
</method>
<method>
<ejb-name>TestBean</ejb-name>
<method-intf>Local</method-intf>
<method-name>sayHello797</method-name>
<method-params/>

... ...

The huge amount of computation to match up roles and methods, and potential xml overriding, may have consumed the bulk of the time.

Nithya, any idea?

Comment by Cheng Fang [ 23/May/11 ]

Why fix this issue in 3.1.1?
To improve deployment performance of ejb apps.

Which is the targeted build of 3.1.1 for this fix?
3.1.1_b06, or the next build.

Do regression tests exist for this issue?
Manual tests to measure the deployment performance.

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

Comment by scatari [ 23/May/11 ]

Approved for 3.1.1.

Comment by Cheng Fang [ 23/May/11 ]

Committed revision 47026 to trunk

Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/MethodDescriptor.java
Sending ejb/ejb-container/src/main/java/com/sun/ejb/containers/AbstractSingletonContainer.java
Sending ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java
Sending verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/ejb/elements/MethodsExist.java

Comment by Cheng Fang [ 23/May/11 ]

Committed revision 47032 to 3.1.1 branch.

Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/MethodDescriptor.java
Sending ejb/ejb-container/src/main/java/com/sun/ejb/containers/AbstractSingletonContainer.java
Sending ejb/ejb-container/src/main/java/com/sun/ejb/containers/BaseContainer.java
Sending verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/ejb/elements/MethodsExist.java

Comment by Cheng Fang [ 23/May/11 ]

Assign to security for further evaluation.

Comment by james100 [ 09/Jun/11 ]

I downloaded 3.1.1 b06.
My app deployment went from over 400 seconds to about 150 seconds while still not blindingly fast it is a big improvement and makes the test/deploy cycle usable.
Thanks

Comment by Nithya Ramakrishnan [ 04/Jul/11 ]

We tried to compare the time and policies for a test app (20 methods with overriding RolesAllowed annotations) in v2.1.1 and v3.1.1. It appears that in v2, the policies are generated incorrectly - the RolesAllowed annotations are not being converted to EjbMethodPermissions, while in v3, the conversion in happening and the policies are generated correctly.

So the extra time taken in v3 is therefore justified.

Comment by Nithya Ramakrishnan [ 04/Jul/11 ]

Attaching the granted.policies for the test app in v2.1.1 and v3.1.1. It can be noticed that the EjbMethodPermissions are totally missing in v2.1.1. Please raise a bug for this on v2.1.1

Comment by Nithya Ramakrishnan [ 04/Jul/11 ]

granted.policies for v2.1.1 and v3.1.1





[GLASSFISH-4302] allows GUI to restart server Created: 28/Feb/08  Updated: 09/Nov/11  Resolved: 09/Nov/11

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

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

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-3677 Add a restart server option to the ad... Resolved
Issuezilla Id: 4,302
Status Whiteboard:

v3-prd-item


 Description   

This is request from community.
Refer to issue#3677



 Comments   
Comment by Anissa Lam [ 28/Feb/08 ]

specify blocking issue 3677

Comment by Anissa Lam [ 28/Feb/08 ]

add keyword

Comment by km [ 02/Mar/08 ]

bnevins.

Comment by Anissa Lam [ 27/Oct/08 ]

Admin console is depending on this to add the feature. #3677 is a P2 for
console and has 17 votes. User has been asking for this feature since v2.0
Changing this to P2.

Comment by Byron Nevins [ 01/May/09 ]

The backend support for restart domain has been in place for 3 weeks now.

RestartDomainCommand
asadmin restart-domain

Comment by rkolar02 [ 09/Nov/11 ]

This can be closed. its already done.

Comment by Anissa Lam [ 09/Nov/11 ]

Thats true, restart domain (DAS) is supported in the console since 3.0.1.
closing issue.





[GLASSFISH-16455] Problem using https webservice client with mutual authentication Created: 26/Apr/11  Updated: 08/Nov/11  Resolved: 08/Nov/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: 3.1.1, 4.0

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

Red Hat Linux 2.6.18-92.el5 x86_64 x86_64 x86_64 GNU/Linux


Tags: 3_1-next, 3_1_1-exclude, keystore, masterpassword, truststore, webservice

 Description   

Scenario:
Cluster with two instances, one running on a local-node (INST_CLU_LOCAL) and another running on a remote-node (INST_CLU_REMOTE).

Issue:
I have a cluster that run a webservice client that consumes a service that requires mutual authentication. Everything works fine when the request starts from INST_CLU_LOCAL, but when the client starts from INST_CLU_REMOTE the follow error is trown
([#|2011-04-26T10:14:52.807-0300|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=146;_ThreadName=Thread-2;|AxisFault
faultCode:

{http://schemas.xmlsoap.org/soap/envelope/}

Server.userException
faultSubcode:
faultString: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
faultActor:
faultNode:
faultDetail:

{http://xml.apache.org/axis/}

stackTrace:javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at br.inf.portalfiscal.www.cte.wsdl.CTeDistribuicaoRFB.CTeDistribuicaoRFBSoapStub.cteDistribuicao(CTeDistribuicaoRFBSoapStub.java:179)
at br.gov.ce.sefaz.cte.facade.CTeFacade.cteDistribuicao(CTeFacade.java:62)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.cteDistribuicao(RecuperarCTEReceitaTimer.java:146)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.timeout(RecuperarCTEReceitaTimer.java:89)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4033)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1835)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2708)
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.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

{http://xml.apache.org/axis/}

hostname:sd2awj12.sefazce.corp

javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:154)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at br.inf.portalfiscal.www.cte.wsdl.CTeDistribuicaoRFB.CTeDistribuicaoRFBSoapStub.cteDistribuicao(CTeDistribuicaoRFBSoapStub.java:179)
at br.gov.ce.sefaz.cte.facade.CTeFacade.cteDistribuicao(CTeFacade.java:62)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.cteDistribuicao(RecuperarCTEReceitaTimer.java:146)
at br.gov.ce.sefaz.cte.timer.RecuperarCTEReceitaTimer.timeout(RecuperarCTEReceitaTimer.java:89)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:149)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4033)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1835)
at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:108)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2708)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.Fut|#]

[#|2011-04-26T10:14:52.808-0300|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=146;_ThreadName=Thread-2;|ureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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:619)
Caused by: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)
... 42 more

#])

I think that is a keystore password issue because I have changed the masterpassword, but I used --savemasterpassword and can manage my cluster trought the admin_gui.



 Comments   
Comment by kumarjayanti [ 18/May/11 ]

Not a 3.1.1 blocker. It is not clear that it is a GlassFish or a Metro WebServices problem. The user is using Apache AXIS webservice library and the SSL handshake error has Apache Axis calls at the bottom of the stack trace

Caused by: javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:198)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:188)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloRequest(ClientHandshaker.java:286)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:114)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:525)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:465)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:746)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.java:583)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143)

Comment by mathcunha [ 21/May/11 ]

Hi,

I also figured out that the domain JDK was 1.6_14 and remote jdk was 1.6_21, and to make it works I had to enable the flag java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "true");. After that the problem was gone.

Is it a bug?!

Thank you

Comment by Tim Quinn [ 21/May/11 ]

If you have not already found it, please read through this article:

http://java.sun.com/javase/javaseforbusiness/docs/TLSReadme.html

which contains abundant information about this SSL handshaking issue.

GlassFish 3.1 and later are supported only with Java 1.6.0_22 or later for exactly this reason.

Comment by kumarjayanti [ 22/May/11 ]

http://weblogs.java.net/blog/kumarjayanti/archive/2010/11/18/ssl-renegotiation-issue-fixed-jdk16022?force=924

marking issue fixed.





[GLASSFISH-16725] [regression] ClassLoadingException from monitoring code during server start Created: 24/May/11  Updated: 03/Nov/11  Resolved: 17/Oct/11

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

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

Tags: 3_1_1-scrubbed

 Description   

I am at svn rev 47063 in my 3.1.1 workspace. Only thing I have done is run QLs. Now when I start GlassFish using "java -jar glassfish.jar" command, I see this message:
[#|2011-05-25T09:52:44.996+0530|WARNING|glassfish3.1|org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer|_ThreadID=10;_ThreadName=main;|Error while getting Instrumentation object from ProbeAgentmain
java.lang.ClassNotFoundException: org.glassfish.flashlight.agent.ProbeAgentMain
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.getInstrumentation(ProbeProviderClassFileTransformer.java:128)
at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.transform(ProbeProviderClassFileTransformer.java:79)
at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.transformProbes(FlashlightProbeClientMediator.java:261)
at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.registerListener(FlashlightProbeClientMediator.java:169)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.registerStatsProviderToFlashlight(StatsProviderManagerDelegateImpl.java:643)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.enableStatsProvider(StatsProviderManagerDelegateImpl.java:394)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.tryToRegister(StatsProviderManagerDelegateImpl.java:191)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.register(StatsProviderManagerDelegateImpl.java:157)
at org.glassfish.external.probe.provider.StatsProviderManager.registerStatsProvider(StatsProviderManager.java:91)
at org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:66)
at org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:57)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:172)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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)

#]

[#|2011-05-25T09:52:45.015+0530|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|GlassFish Server Open Source Edition 3.1.1-SNAPSHOT (ss141213-private) startup time : Felix (9,566ms), startup services(1,363ms), total(10,929ms)|#]

[#|2011-05-25T09:52:45.425+0530|WARNING|glassfish3.1|org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer|_ThreadID=10;_ThreadName=main;|Error while getting Instrumentation object from ProbeAgentmain
java.lang.ClassNotFoundException: org.glassfish.flashlight.agent.ProbeAgentMain
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.getInstrumentation(ProbeProviderClassFileTransformer.java:128)
at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.transform(ProbeProviderClassFileTransformer.java:79)
at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.transformProbes(FlashlightProbeClientMediator.java:261)
at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.registerListener(FlashlightProbeClientMediator.java:169)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.registerStatsProviderToFlashlight(StatsProviderManagerDelegateImpl.java:643)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.enableStatsProvider(StatsProviderManagerDelegateImpl.java:394)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.tryToRegister(StatsProviderManagerDelegateImpl.java:191)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.register(StatsProviderManagerDelegateImpl.java:157)
at org.glassfish.external.probe.provider.StatsProviderManager.registerStatsProvider(StatsProviderManager.java:91)
at org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:66)
at org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:57)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.initProperties(JavaEETransactionManagerSimplified.java:238)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.postConstruct(JavaEETransactionManagerSimplified.java:162)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.jvnet.hk2.component.Habitat.getByContract(Habitat.java:1042)
at com.sun.enterprise.transaction.startup.TransactionRecoveryWrapper.onReady(TransactionRecoveryWrapper.java:94)
at com.sun.enterprise.transaction.startup.TransactionRecoveryWrapper$1.event(TransactionRecoveryWrapper.java:81)
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)

#]


 Comments   
Comment by Mahesh Kannan [ 25/May/11 ]

3_1_1-scrubbed

Comment by Byron Nevins [ 26/May/11 ]

ProbeProviderClassFileTransformer.java gave up very easily.

Now if it can't load the agent class it calls the code that attaches the agent to the JVM dynamically.

Comment by Byron Nevins [ 26/May/11 ]

The solution is so trivial I just went ahead and assigned it to me and fixed it in both branches.

3.2

Sending framework\src\main\java\org\glassfish\flashlight\transformer\ProbeProviderClassFileTransformer.java
Transmitting file data .
Committed revision 47110.

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

3.1.1

Sending framework\src\main\java\org\glassfish\flashlight\transformer\ProbeProviderClassFileTransformer.java
Transmitting file data .
Committed revision 47111.

Comment by Byron Nevins [ 26/May/11 ]

Next Bug:

No EJBContainer provider available Provider named org.glassfish.ejb.embedded.EJBContainerProviderImpl threw unexpected exception at create EJBContainer: java.lang.RuntimeException java.lang.RuntimeException: java.lang.NoClassDefFoundError: com/sun/tools/attach/VirtualMachine at org.glassfish.internal.embedded.Server.<init>(Server.java:290) at org.glassfish.internal.embedded.Server.<init>(Server.java:66) at org.glassfish.internal.embedded.Server$Builder.build(Server.java:176) at org.glassfish.internal.embedded.Server$Builder.build(Server.java:158) at org.glassfish.ejb.embedded.EJBContainerProviderImpl.init(EJBContainerProviderImpl.java:175) at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:126) at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127) at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:102) at com.acme.Client.test(Client.java:86) at com.acme.Client.testEmbedded(Client.java:72) 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.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:604) at org.testng.internal.Invoker.invokeMethod(Invoker.java:470) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:564) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:830) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) at org.testng.TestRunner.runWorkers(TestRunner.java:678) at org.testng.TestRunner.privateRun(TestRunner.java:624) at org.testng.TestRunner.run(TestRunner.java:495) at org.testng.SuiteRunner.runTest(SuiteRunner.java:300) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:295) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:275) at org.testng.SuiteRunner.run(SuiteRunner.java:190) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:792) at org.testng.TestNG.runSuitesLocally(TestNG.java:765) at org.testng.TestNG.run(TestNG.java:699) at org.testng.TestNG.privateMain(TestNG.java:824) at org.testng.TestNG.main(TestNG.java:802) Caused by: java.lang.NoClassDefFoundError: com/sun/tools/attach/VirtualMachine at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.attachAgent(FlashlightProbeClientMediator.java:351) at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.getAgentClass(ProbeProviderClassFileTransformer.java:145) at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.getInstrumentation(ProbeProviderClassFileTransformer.java:129) at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.transform(ProbeProviderClassFileTransformer.java:80) at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.transformProbes(FlashlightProbeClientMediator.java:261) at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.registerListener(FlashlightProbeClientMediator.java:169) at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.registerStatsProviderToFlashlight(StatsProviderManagerDelegateImpl.java:643) at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.enableStatsProvider(StatsProviderManagerDelegateImpl.java:394) at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.tryToRegister(StatsProviderManagerDelegateImpl.java:191) at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.register(StatsProviderManagerDelegateImpl.java:157) at org.glassfish.external.probe.provider.StatsProviderManager.registerStatsProvider(StatsProviderManager.java:91) at org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:66) at org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:57) at com.sun.enterprise.v3.services.impl.monitor.GrizzlyMonitoring.registerThreadPoolStatsProviderGlobal(GrizzlyMonitoring.java:270) at com.sun.enterprise.v3.services.impl.GrizzlyService.registerMonitoringStatsProviders(GrizzlyService.java:647) at com.sun.enterprise.v3.services.impl.GrizzlyService.postConstruct(GrizzlyService.java:419) at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131) at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91) at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82) at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67) at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139) at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76) 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 org.glassfish.internal.embedded.Server.<init>(Server.java:273) ... 31 more Caused by: java.lang.ClassNotFoundException: com.sun.tools.attach.VirtualMachine at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) ... 57 more

Stacktrace

javax.ejb.EJBException: No EJBContainer provider available
Provider named org.glassfish.ejb.embedded.EJBContainerProviderImpl threw unexpected exception at create EJBContainer:
java.lang.RuntimeException
java.lang.RuntimeException: java.lang.NoClassDefFoundError: com/sun/tools/attach/VirtualMachine
at org.glassfish.internal.embedded.Server.<init>(Server.java:290)
at org.glassfish.internal.embedded.Server.<init>(Server.java:66)
at org.glassfish.internal.embedded.Server$Builder.build(Server.java:176)
at org.glassfish.internal.embedded.Server$Builder.build(Server.java:158)
at org.glassfish.ejb.embedded.EJBContainerProviderImpl.init(EJBContainerProviderImpl.java:175)
at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:126)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:102)
at com.acme.Client.test(Client.java:86)
at com.acme.Client.testEmbedded(Client.java:72)
Caused by: java.lang.NoClassDefFoundError: com/sun/tools/attach/VirtualMachine
at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.attachAgent(FlashlightProbeClientMediator.java:351)
at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.getAgentClass(ProbeProviderClassFileTransformer.java:145)
at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.getInstrumentation(ProbeProviderClassFileTransformer.java:129)
at org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer.transform(ProbeProviderClassFileTransformer.java:80)
at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.transformProbes(FlashlightProbeClientMediator.java:261)
at org.glassfish.flashlight.impl.client.FlashlightProbeClientMediator.registerListener(FlashlightProbeClientMediator.java:169)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.registerStatsProviderToFlashlight(StatsProviderManagerDelegateImpl.java:643)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.enableStatsProvider(StatsProviderManagerDelegateImpl.java:394)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.tryToRegister(StatsProviderManagerDelegateImpl.java:191)
at org.glassfish.admin.monitor.StatsProviderManagerDelegateImpl.register(StatsProviderManagerDelegateImpl.java:157)
at org.glassfish.external.probe.provider.StatsProviderManager.registerStatsProvider(StatsProviderManager.java:91)
at org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:66)
at org.glassfish.external.probe.provider.StatsProviderManager.register(StatsProviderManager.java:57)
at com.sun.enterprise.v3.services.impl.monitor.GrizzlyMonitoring.registerThreadPoolStatsProviderGlobal(GrizzlyMonitoring.java:270)
at com.sun.enterprise.v3.services.impl.GrizzlyService.registerMonitoringStatsProviders(GrizzlyService.java:647)
at com.sun.enterprise.v3.services.impl.GrizzlyService.postConstruct(GrizzlyService.java:419)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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 org.glassfish.internal.embedded.Server.<init>(Server.java:273)
... 31 more
Caused by: java.lang.ClassNotFoundException: com.sun.tools.attach.VirtualMachine
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 57 more

at javax.ejb.embeddable.EJBContainer.reportError(EJBContainer.java:216)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:146)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:102)
at com.acme.Client.test(Client.java:86)
at com.acme.Client.testEmbedded(Client.java:72)
... Removed 44 stack frames

Page generated: May 26, 2011 3:28:39 AMHudson ver. 1.396

Comment by Byron Nevins [ 26/May/11 ]

Attach classes can't be found by embedded server

Comment by Byron Nevins [ 26/May/11 ]

3.2 --> 47117
3.1.1 --> 47118

Log Message:
------------
JIRA 16725
It was catching Exception. And allowing an *ERROR* (NoClassDefFoundError) to pass through and foul things up!
Fix: catch Throwable

Comment by Mahesh Kannan [ 26/May/11 ]

I updated my v3 workspace to svn revision: 47126 and could run QL successfully.

Here is what I found in the server log:

[#|2011-05-26T16:17:08.282-0700|INFO|glassfish3.1|org.glassfish.flashlight.transformer.ProbeProviderClassFileTransformer|_ThreadID=59;_ThreadName=Thread-1;|Successfully got INSTRUMENTATION: sun.instrument.InstrumentationImpl@697bbc44|#]

Sahoo: Could you update your v3 workspace and run QL

Comment by Mahesh Kannan [ 17/Oct/11 ]

This has been resolved

Comment by Mahesh Kannan [ 03/Nov/11 ]

Already fixed





[GLASSFISH-16872] ServletContainerInitializer API contract broken Created: 16/Jun/11  Updated: 01/Nov/11  Resolved: 01/Jul/11

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1.1

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

Linux 2.6.35-28-generic #50-Ubuntu SMP x86_64 GNU/Linux
GlassFish Server Open Source Edition 3.1 (build 43)


Attachments: Text File server.log    
Issue Links:
Dependency
blocks GLASSFISH-16118 Registering the Jersey servlet applic... Closed
blocks GLASSFISH-16635 context-root not available after depl... Closed

 Description   

ServletContainerInitializer.onStartup method is invoked with incomplete list of classes
The behavior is non-deterministic and hard to debug.

This issue is the root cause for http://java.net/jira/browse/GLASSFISH-16635
and http://java.net/jira/browse/GLASSFISH-16118

JerseyServletContainerInitializer, which is annotated
with @HandlesTypes(

{Path.class, Provider.class, javax.ws.rs.core.Application.class}

)
is sometimes invoked (via it's onStartup method) without application
classes extending javax.ws.rs.core.Application class. This breaks the ServletContainerInitializer API contract.

To reproduce, please see http://java.net/jira/browse/GLASSFISH-16118, which has
a SimpleServlet.war application attached. I have deployed the application onto a fresh
GFv3.1 container, undeployed, then deployed again and restarted the container.
After the last restart, the issue reproduced. Attaching my server.log file
to this report. To see what happens, i have added the following lines to domain conf/logging.properties
file:

org.apache.catalina.core.StandardContext.level=FINEST
com.sun.jersey.spi.service.ServiceFinder.level=FINEST
com.sun.jersey.server.impl.container.servlet.JerseyServletContainerInitializer.level=FINEST

Here is what i see in the server.log file for the two latest re-start of the application:

[#|2011-06-16T13:33:21.256+0200|FINE|glassfish3.1|org.apache.catalina.core.StandardContext|_ThreadID=21;_ThreadName=Threa
d-1;ClassName=org.apache.catalina.core.StandardContext;MethodName=callServletContainerInitializers;|Calling ServletContai
nerInitializer [class com.sun.jersey.server.impl.container.servlet.JerseyServletContainerInitializer] onStartup with clas
ses [class com.sun.jersey.samples.servlet.resources.ResourceBean1, class com.sun.jersey.api.core.ScanningResourceConfig,
class com.sun.jersey.samples.servlet.resources.ResourceBean2, class com.sun.jersey.api.core.ClasspathResourceConfig, clas
s com.sun.jersey.api.core.ApplicationAdapter, class com.sun.jersey.api.core.ResourceConfig, class com.sun.jersey.samples.
servlet.resources.MasterResourceBean, class com.sun.jersey.api.core.DefaultResourceConfig, class com.sun.jersey.samples.s
ervlet.resources.ResourceBean4, class com.sun.jersey.api.core.WebAppResourceConfig, class com.sun.jersey.api.core.Package
sResourceConfig, class com.sun.jersey.samples.servlet.resources.ResourceBean3, class com.sun.jersey.api.core.ClassNamesRe
sourceConfig, class com.sun.jersey.server.impl.application.DeferredResourceConfig, class com.sun.jersey.samples.servlet.r
esources.MyApplication]|#]

[#|2011-06-16T13:33:54.485+0200|FINE|glassfish3.1|org.apache.catalina.core.StandardContext|_ThreadID=10;_ThreadName=Threa
d-1;ClassName=org.apache.catalina.core.StandardContext;MethodName=callServletContainerInitializers;|Calling ServletContai
nerInitializer [class com.sun.jersey.server.impl.container.servlet.JerseyServletContainerInitializer] onStartup with clas
ses [class com.sun.jersey.samples.servlet.resources.ResourceBean4, class com.sun.jersey.samples.servlet.resources.MasterR
esourceBean, class com.sun.jersey.samples.servlet.resources.ResourceBean1, class com.sun.jersey.samples.servlet.resources
.ResourceBean2, class com.sun.jersey.samples.servlet.resources.ResourceBean3]|#]

The key class, com.sun.jersey.samples.servlet.resources.MyApplication, is missing in the later call,
which is causing the JAX-RS application servlet not to be registered.

I think, the problematic code is in the org.glassfish.web.loader.ServletContainerInitializerUtil class,
where two methods are utilized for interest list construction, both called checkAgainstInterestList.
When the first one of them is utilized, the problem reproduces.



 Comments   
Comment by Jakub Podlesak [ 16/Jun/11 ]

When added the following JVM property, it seems i can not reproduce the issue any more:

asadmin create-jvm-options -Dorg.glassfish.web.parsing=true

but then also the application context path changes to SimpleServlet,
so that the main application URI changes to:

http://localhost:8080/SimpleServlet/resources/start

The above property controls, which checkAgainstInterestList method gets called
in the above mentioned ServletContainerInitializerUtil class
to put together the ServletContainerInitializer interest list:

if (types==null || Boolean.getBoolean("org.glassfish.web.parsing")) {
ClassDependencyBuilder classInfo = new ClassDependencyBuilder();
for(URL u : ((URLClassLoader)cl).getURLs()) {
String path = u.getPath();
try {
if(path.endsWith(".jar")) {
JarFile jf = new JarFile(path);
try {
Enumeration<JarEntry> entries = jf.entries();
while(entries.hasMoreElements()) {
JarEntry anEntry = entries.nextElement();
if(anEntry.isDirectory())
continue;
if(!anEntry.getName().endsWith(".class"))
continue;
InputStream jarInputStream = null;
try {
jarInputStream = jf.getInputStream(anEntry);
int size = (int) anEntry.getSize();
byte[] classData = new byte[size];
for(int bytesRead = 0; bytesRead < size

{ int r2 = jarInputStream.read(classData, bytesRead, size - bytesRead); bytesRead += r2; }

classInfo.loadClassData(classData);
} catch (Throwable t) {
if (log.isLoggable(Level.FINE)) {
log.log(Level.FINE,
"servletContainerInitializerUtil.classLoadingError",
new Object[]

{ anEntry.getName(), t.toString()}

);
}
continue;
} finally {
if(jarInputStream != null)

{ jarInputStream.close(); }

}
}
} finally

{ jf.close(); }

} else {
File file = new File(path);
if (file.exists()) {
if (file.isDirectory())

{ scanDirectory(file, classInfo); }

else

{ log.log(Level.WARNING, "servletContainerInitializerUtil.invalidUrlClassLoaderPath", path); }

}
}
} catch(IOException ioex) {
String msg = rb.getString(
"servletContainerInitializerUtil.ioError");
msg = MessageFormat.format(msg,
new Object[]

{ path }

);
log.log(Level.SEVERE, msg, ioex);
return null;
}
}

initializerList = checkAgainstInterestList(classInfo, interestList, initializerList, cl);
} else

{ initializerList = checkAgainstInterestList(types, interestList, initializerList, cl); }

}

Comment by kchung [ 23/Jun/11 ]

I've traced the cause of the problem to the method com.sun.enterprise.v3.server.ApplicationLifecycle.getDeployableTypes(). This method is supposed to collect all Types related to the application at deployment and store them in the deployment context. However, on some calls (described below), at the end of this method no such Type exist for the class "javax.ws.rs.core.Application". Therefore the web container cannot provide any info about the classes that extend javax.ws.rs.core.Application.

To force the failure, use the following steps:

1. Start with a fresh Glassfish.
asadmin start-domain
2. asadmin deploy simple_servlet.war
3. asadmin stop-domain
4. asadmin deploy --force=true simple_servlet.war

I suspect there are issues with Types cache with the deployment context.

Comment by dochez [ 01/Jul/11 ]

Resolved by integrating Hk2 1.1.3

The issue was that we were creating ProxyTypes of type Interface when visiting fields, this was creating duplicate entries in particular javax.rs.core.Application one which was creating wrong results.





[GLASSFISH-16359] ClassNotFoundException with exploded JARs in WEB-INF/lib Created: 15/Apr/11  Updated: 21/Oct/11  Resolved: 21/Oct/11

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

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

Attachments: File project-compacted-jar.war     File project-exploded-jar-wt-beans-xml.war     File project-exploded-jar.war    
Tags: 3_1_1-scrubbed

 Description   

I´m getting ClassNotFoundException trying to deploy a web app with an exploded jar in WEB-INF/lib. Steps to reproduce:

1. Create a JAR project
2. Create a web application
3. Put the exploded JAR project into WEB-INF/lib
4. Create a beans.xml file and put it into WEB-INF/lib
5. Import some class of the JAR project into a class of the web project

The problem only occurs if the web-project have beans.xml into WEB-INF/lib

Forum reference: http://www.java.net/forum/topic/glassfish/glassfish/classnotfoundexception-exploded-project-0

I attached 3 projects:

  • project-compacted-jar.war: The JAR is compacted (not exploded) in WEB-INF/lib: the error does NOT happen
  • project-exploded-jar.war: The JAR is exploded in WEB-INF/lib: the error does happen
  • project-exploded-jar-wt-beans-xml.war: The JAR is exploded in WEB-INF/lib but the web project doesn´t have beans.xml: the error does NOT happen

Exception shown while deploying project-exploded-jar.war:

INFO: Portable JNDI names for EJB MyService : [java:global/project-exploded-jar/MyService, java:global/project-exploded-jar/MyService!web.MyService]
SEVERE: ectcore.jar.core.MyUtilityClass
java.lang.ClassNotFoundException: ectcore.jar.core.MyUtilityClass
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1518)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
at org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:340)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:148)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:128)
at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:120)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:334)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
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: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:619)



 Comments   
Comment by Hong Zhang [ 15/Apr/11 ]

As the issues seems cdi specific, assign to cdi team for initial evaluation.

Comment by Sivakumar Thyagarajan [ 21/Oct/11 ]

This issue has been fixed in 3.1.1. I could not reproduce this issue with 3.1.2 and trunk builds. Marking this as resolved in 3.1.1





[GLASSFISH-16046] lbconfigurator should report error message on unsupported OS Created: 18/Feb/11  Updated: 21/Oct/11  Resolved: 21/Oct/11

Status: Resolved
Project: glassfish
Component/s: load_balancer
Affects Version/s: None
Fix Version/s: 3.1.1

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

Tags: 3_1-exclude, 3_1_1-scrubbed

 Description   

Currently on MAC OS, load-balancer configurator runs without notifying that this is unsupported platform. This need to be fixed.



 Comments   
Comment by scatari [ 10/Jun/11 ]

Not serious enough to be considered for 3.1.1 as MacOS is not the platform for LB tier.

Comment by kshitiz_saxena [ 13/Jun/11 ]

This issue is already fixed in lbconfigurator 3.1.1 build.

Comment by kshitiz_saxena [ 21/Oct/11 ]

Reopening to add fix version

Comment by kshitiz_saxena [ 21/Oct/11 ]

Fixed in version 3.1.1





[GLASSFISH-16329] Property with "" value is not deleted Created: 08/Apr/11  Updated: 20/Oct/11  Resolved: 27/May/11

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

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_1-approved, 3_1_1-scrubbed

 Description   

go to JDBC resource and add the following property:

empty ()
foo foovalue
abc abcValue

post endpoint: "http://0.0.0.0:4848/management/domain/resources/jdbc-resource/opentaxi/property.json"
payload: "[

{"description":"","name":"abc","value":"abcValue"}

,

{"description":"","name":"empty","value":""}

,

{"description":"","name":"foo","value":"fooValue"}

]"

this is persisted in domain.xml as expected correctly.
<property name="abc" value="abcValue;"></property>
<property name="empty" value=""></property>
<property name="foo" value="foovalue"></property>

now, try remove "empty" and "foo" property and just have "abc" remains.

this will result in
posting to endpoint: "http://0.0.0.0:4848/management/domain/resources/jdbc-resource/opentaxi/property.json"
with payload: "[

{"description":"","name":"abc","value":"abcValue"}

]"

I will expect ONLY 'abc' property will stay, foo and empty should be gone.

but you will see that in domain.xml,
<property name="empty" value=""></property>
<property name="abc" value="abcValue"></property>

"empty" still stay.
This is a bug. Only "abc" should still exist.



 Comments   
Comment by Jason Lee [ 24/May/11 ]
  • Why fix this issue in 3.1.1?
    The inability to delete properties like these is a regression from previous versions.
  • Which is the targeted build of 3.1.1 for this fix?
    If the calendar is still correct, this should be in b09.
  • Do regression tests exist for this issue?
    I have added a test to the REST suite.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    The REST and Console Dev Tests.
Diff
Index: src/test/java/org/glassfish/admin/rest/PropertiesBagTest.java
===================================================================
--- src/test/java/org/glassfish/admin/rest/PropertiesBagTest.java	(revision 47043)
+++ src/test/java/org/glassfish/admin/rest/PropertiesBagTest.java	(working copy)
@@ -82,12 +82,41 @@
     public void serverProperties() {
         createAndDeleteProperties(URL_SERVER_PROPERTIES);
     }
-    
+
     @Test
+    public void propsWithEmptyValues() {
+        List<Map<String, String>> properties = new ArrayList<Map<String, String>>();
+        final String empty = "empty" + generateRandomNumber();
+        final String foo = "foo" + generateRandomNumber();
+        final String bar = "bar" + generateRandomNumber();
+        final String abc = "abc" + generateRandomNumber();
+
+        properties.add(createProperty(empty,""));
+        properties.add(createProperty(foo,"foovalue"));
+        properties.add(createProperty(bar,"barvalue"));
+        createProperties(URL_DERBYPOOL_PROPERTIES, properties);
+        List<Map<String, String>> newProperties = getProperties(get(URL_DERBYPOOL_PROPERTIES));
+
+        assertTrue(isPropertyFound(newProperties, empty));
+        assertTrue(isPropertyFound(newProperties, foo));
+        assertTrue(isPropertyFound(newProperties, bar));
+
+        properties.clear();
+        properties.add(createProperty(abc,"abcvalue"));
+        createProperties(URL_DERBYPOOL_PROPERTIES, properties);
+        newProperties = getProperties(get(URL_DERBYPOOL_PROPERTIES));
+
+        assertTrue(isPropertyFound(newProperties, abc));
+        assertFalse(isPropertyFound(newProperties, empty));
+        assertFalse(isPropertyFound(newProperties, foo));
+        assertFalse(isPropertyFound(newProperties, bar));
+    }
+
+    @Test
     public void testOptimizedPropertyHandling() {
         // First, test changing one property and adding a new
         List<Map<String, String>> properties = new ArrayList<Map<String, String>>();
-        properties.add(createProperty("PortNumber","1527")); 
+        properties.add(createProperty("PortNumber","1527"));
         properties.add(createProperty("Password","APP"));
         properties.add(createProperty("User","APP"));
         properties.add(createProperty("serverName","localhost"));
@@ -95,7 +124,7 @@
         properties.add(createProperty("connectionAttributes",";create=false"));
         properties.add(createProperty("foo","bar","test"));
         createProperties(URL_DERBYPOOL_PROPERTIES, properties);
-        
+
         List<Map<String, String>> newProperties = getProperties(get(URL_DERBYPOOL_PROPERTIES));
         for (Map<String, String> property : newProperties) {
             if (property.get("name").equals("connectionAttributes")) {
@@ -105,12 +134,12 @@
                 assertEquals("test", property.get("description"));
             }
         }
-        
+
         // Test updating the description and value
         properties.clear();
         properties.add(createProperty("foo","bar 2","test 2"));
         createProperties(URL_DERBYPOOL_PROPERTIES, properties);
-        
+
         newProperties = getProperties(get(URL_DERBYPOOL_PROPERTIES));
         assertNotSame(1, newProperties);
         for (Map<String, String> property : newProperties) {
@@ -119,7 +148,7 @@
                 assertEquals("test 2", property.get("description"));
             }
         }
-        
+
         // Now test changing that property back and deleting the new one
         properties.clear();
         properties.add(createProperty("PortNumber","1527"));
@@ -128,9 +157,9 @@
         properties.add(createProperty("serverName","localhost"));
         properties.add(createProperty("DatabaseName","sun-appserv-samples"));
         properties.add(createProperty("connectionAttributes",";create=true"));
-        
+
         createProperties(URL_DERBYPOOL_PROPERTIES, properties);
-        
+
         newProperties = getProperties(get(URL_DERBYPOOL_PROPERTIES));
         for (Map<String, String> property : newProperties) {
             if (property.get("name").equals("connectionAttributes")) {
@@ -140,14 +169,14 @@
             }
         }
     }
-    
+
     // This operation is taking a REALLY long time from the console, probably due
     // to improper properties handling when create the RA config.  However, when
     // updating the config's properties, we need to verfiy that only the changed
     // properties are updated, as the broker restarts after every property is
-    // saved. This test will create the jmsra config with a set of properties, 
+    // saved. This test will create the jmsra config with a set of properties,
     // then update only one the object's properties, which should be a very quick,
-    // inexpensive operation.  
+    // inexpensive operation.
     @Test
     public void testJmsRaCreateAndUpdate() {
         List<Map<String, String>> props = new ArrayList<Map<String, String>>(){{
@@ -174,12 +203,12 @@
             put("threadPoolIds","thread-pool-1");
             put("property", propertyList);
         }};
-        
+
         final String URL = "/domain/resources/resource-adapter-config";
         delete(URL+"/jmsra");
         ClientResponse response = post(URL, attrs);
         assertTrue(isSuccess(response));
-        
+
         // Change one property value (AddressListIterations) and update the object
         props = new ArrayList<Map<String, String>>(){{
            add(createProperty("AddressListBehavior", "random"));
@@ -202,7 +231,7 @@
 
         delete(URL+"/jmsra");
     }
-    
+
     protected String buildPropertyList(List<Map<String, String>> props) {
         StringBuilder sb = new StringBuilder();
         String sep = "";
@@ -210,7 +239,7 @@
             sb.append(sep).append(prop.get("name")).append("=").append(prop.get("value"));
             sep = ":";
         }
-        
+
         return sb.toString();
     }
 
@@ -229,7 +258,7 @@
         response = delete(endpoint);
         checkStatusForSuccess(response);
     }
-    
+
     protected Map<String, String> createProperty(final String name, final String value) {
         return createProperty(name, value, "");
     }
Index: src/main/java/org/glassfish/admin/rest/Util.java
===================================================================
--- src/main/java/org/glassfish/admin/rest/Util.java	(revision 47043)
+++ src/main/java/org/glassfish/admin/rest/Util.java	(working copy)
@@ -307,7 +307,7 @@
 
         for (Map.Entry<String, String> entry : data.entrySet()) {
             String currentValue = currentValues.get(setBasePath + entry.getKey());
-            if ((currentValue == null) || (!currentValue.equals(entry.getValue()))) {
+            if ((currentValue == null) || entry.getValue().equals("") || (!currentValue.equals(entry.getValue()))) {
                 parameters.add("DEFAULT", setBasePath + entry.getKey() + "=" + entry.getValue());
             }
         }

Comment by scatari [ 24/May/11 ]

Approved for 3.1.1.

Comment by Jason Lee [ 27/May/11 ]

Fix committed to trunk and branch (r47139).





[GLASSFISH-11587] enabling compression result in random blank page Created: 18/Feb/10  Updated: 19/Oct/11  Resolved: 19/Oct/11

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: V3
Fix Version/s: 3.1.1

Type: Bug Priority: Minor
Reporter: thierryd Assignee: Ryan Lubke
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: All


Issuezilla Id: 11,587

 Description   

When I enable compression, I randomly have page that return a content length of
0 (zero). The compression settings that I have is:

compression: on
Compressible Mime Types: text/html,text/xml,text/plain

It seems that when these errors occurs, the servlet is not even reached (I see
no activity in my filters). If I do a refresh after I have the blank page, the
page is returned with content (and I do see activity in my filters).

Here an example of the errors as seen in my access logs (notice the server code
returned is 200, but the content length is 0):
x.x.x.x - - [18/Feb/2010:06:25:46 -0500] "GET /photos.do?id=9780 HTTP/1.1" 200 0
"-"
x.x.x.x - - [18/Feb/2010:07:41:40 -0500] "HEAD / HTTP/1.1" 200 0 "-"

The problem does not occur is the compression is turned off.



 Comments   
Comment by jluehe [ 18/Feb/10 ]

...

Comment by Ryan Lubke [ 23/Feb/10 ]

Looking into this one.

I'm curious. Have you tried replicating the issue without Filters involved?

Comment by thierryd [ 23/Feb/10 ]

Thanks for looking at this issue.

Another user has made a post about this issue:
http://forums.java.net/jive/thread.jspa?messageID=387402&tstart=0

The issue appears at random. I haven't been able to the steps to generate the
problem. I suggest you investigate using the comment made in the post first
("usually it happens after a long period of inactivity, like early in the
morning.. perhaps some server wake up process or server hibernation after long
inactivity...)

As for the filters, I haven't tried replicating the problem without them. It
would break our application anyway since the filters check for session cookie,
etc. We have a bunch of logging statement in all filters and I know for sure
that they are never called (the service layer neither).

I also tried setting logging to FINEST in Glassfish. But I can't seem to find
anything interesting in the log when the error occurs. If you have any
suggestion, please tell me.

Comment by Ryan Lubke [ 23/Feb/10 ]

Thank you for the follow up. We'll see what we can find!

Comment by Ryan Lubke [ 03/Mar/10 ]

So far, no luck in reproducing this by having the server sit unused for 12+ hours.

That said, there's one point we're having a tough time reconciling:

> It seems that when these errors occurs, the servlet is not even reached (I
> see no activity in my filters).

The fact that the there's an access log entry, given the logic flow, implies
that the filter chain should have been hit. I should also note, that
compression isn't enabled until the response is being finished, or content is
being flushed to the client, so it shouldn't have any impact on the request.

Still working through the code for possible instrumentation points.

Comment by oleksiys [ 16/Jun/10 ]

cc myself

Comment by Ryan Lubke [ 21/Jun/10 ]

The grizzly team has made a couple changes in the area of compression which have
recently been integrated.

Could you please try tonight's nightly build or the next 3.1 promoted build
(3.1-b06) and let us know if the issue persists?

Comment by Ryan Lubke [ 06/Oct/10 ]

Have you been able to try a nightly or promoted build of 3.1 to verify the issue having been resolved?

Reducing to P4 for the time being.

Comment by kieranb [ 24/Mar/11 ]

(This is also reported as an issue here: http://java.net/jira/browse/GLASSFISH-16228 )

We have the same issue.

java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)

GlassFish Server Open Source Edition 3.0.1 (build 22)

Linux 2.6.18-164.15.1.el5 #1 SMP Mon Mar 1 10:56:08 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

Red Hat Enterprise Linux Server release 5.4 (Tikanga)

In my testing of gzip in the recent 3.1 release to see if this issue was fixed, I was unable to enable gzip compression - enabling the option had no effect even after a server restart (done in the 'server' profile and both 'on' and 'force' were unsuccesful). This was using JDK1.6.0_22 on Windows 7 Enterprise 64bit.

All tests done using Firefox 3.6 and IE8.

Comment by oleksiys [ 19/Oct/11 ]

has to be fixed in 3.1.1





[GLASSFISH-16696] 3.1.1 startup/deployment performance regression due to corba integration Created: 20/May/11  Updated: 18/Oct/11  Resolved: 18/Oct/11

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: 3.1.1
Fix Version/s: 3.1.1

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

Tags: 3_1_1-approved

 Description   

To track down the cause of the performance regression in 3.1.1 from 3.1, Sathyan and Amit have done iterative performance testing on the builds. Their data shown
one of the regressions (happened around Jan 26th-27th) was due to the corba integration:
http://svnsearch.org/svnsearch/repos/GLASSFISH/search?from=20110126&to=20110127&path=%2Ftrunk%2Fv3&author=kcavanaugh

I am attaching some of the their data below:

Build 44709 from http://hudson-sca.us.oracle.com/job/v3.1.1-PerfRegression/34/
Regular build
==============================================================================
logs/10.1.1/nightly_44709_iterations.jdk25/:
Benchmark Samples Mean Stdev %Diff P Significant
as_developerScenari 10 8.62 0.03 -5.59 0.000 Yes
elapsed_time 10 8.62 0.03 -5.59 0.000 Yes
server_startup 10 3.00 0.02 -6.38 0.001 Yes
deployNaccess 10 3.11 0.02 0.25 0.929 *
footprint 10 143988.00 101.32 -11.12 0.000 Yes
average_redeployN 10 0.84 0.00 -12.76 0.000 Yes
==============================================================================

Web build
==============================================================================
logs/10.1.1/nightly_44709-web_10_iterations.jdk25/:
Benchmark Samples Mean Stdev %Diff P Significant
as_developerScenari 10 7.77 0.03 -1.50 0.026 *
elapsed_time 10 7.77 0.03 -1.50 0.026 *
server_startup 10 2.81 0.02 -4.84 0.000 Yes
deployNaccess 10 2.78 0.02 1.82 0.170 *
footprint 10 124031.20 245.59 -6.28 0.000 Yes
average_redeployN 10 0.73 0.00 -1.70 0.000 Yes
==============================================================================
=========================================================================================

Build 44713 from http://hudson-sca.us.oracle.com/job/v3.1.1-PerfRegression/33/
Regular build
==============================================================================
logs/10.1.1/nightly_44713_10_iterations.jdk25/:
Benchmark Samples Mean Stdev %Diff P Significant
as_developerScenari 10 8.61 0.03 -5.41 0.000 Yes
elapsed_time 10 8.61 0.03 -5.41 0.000 Yes
server_startup 10 2.98 0.04 -5.75 0.001 Yes
deployNaccess 10 3.12 0.01 0.05 0.985 *
footprint 10 144116.00 267.45 -11.22 0.000 Yes
average_redeployN 10 0.84 0.00 -12.59 0.000 Yes
==============================================================================

Web build
==============================================================================
logs/10.1.1/nightly_44713-web_10_iterations.jdk25/:
Benchmark Samples Mean Stdev %Diff P Significant
as_developerScenari 10 7.80 0.07 -1.88 0.010 *
elapsed_time 10 7.80 0.07 -1.88 0.010 *
server_startup 10 2.74 0.07 -2.33 0.018 *
deployNaccess 10 2.88 0.01 -1.77 0.177 *
footprint 10 126166.80 85.94 -8.11 0.000 Yes
average_redeployN 10 0.72 0.00 -1.46 0.000 Yes
==============================================================================
=========================================================================================

Build 44706 from http://hudson-sca.us.oracle.com/job/v3.1.1-PerfRegression/31/
Regular build
==============================================================================
logs/10.1.1/nightly_44706_10_iterations.jdk25/:
Benchmark Samples Mean Stdev %Diff P Significant
as_developerScenari 10 8.60 0.02 -5.26 0.001 Yes
elapsed_time 10 8.60 0.02 -5.26 0.001 Yes
server_startup 10 2.98 0.03 -5.71 0.001 Yes
deployNaccess 10 3.11 0.01 0.35 0.898 *
footprint 10 144105.60 181.42 -11.21 0.000 Yes
average_redeployN 10 0.84 0.00 -12.55 0.000 Yes
==============================================================================

Web build
==============================================================================
logs/10.1.1/nightly_44706-web_10_iterations.jdk25/:
Benchmark Samples Mean Stdev %Diff P Significant
as_developerScenari 10 7.74 0.09 -1.10 0.121 *
elapsed_time 10 7.74 0.09 -1.10 0.121 *
server_startup 10 2.72 0.03 -1.74 0.000 Yes
deployNaccess 10 2.80 0.03 1.26 0.338 *
footprint 10 125772.80 498.43 -7.78 0.000 Yes
average_redeployN 10 0.74 0.03 -3.43 0.032 *
==============================================================================



 Comments   
Comment by scatari [ 21/May/11 ]

Pre approving for 3.1.1.

Comment by scatari [ 25/Jun/11 ]

This slow down in perf. has been reduced through improvements obtain through successive checkins(not in ORB) in 3.1.1. Closing this.

Comment by Joe Di Pol [ 18/Oct/11 ]

Reopening to correct fixVersion





[GLASSFISH-16655] Basic CDI / Weld Application leaks Perm Gen, and Heap does not look right Created: 16/May/11  Updated: 17/Oct/11  Resolved: 17/Oct/11

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

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

Java 1.6.0_24 Linux 64


Attachments: PNG File 3.1.1_b7_1000_weld_deploys.png     PNG File CMS-old-gen.png     PNG File CMS-perm-gen.png     File loop.sh     PNG File old_gen.png     PNG File ps+perm_gen.png     PNG File ps_eden.png     Zip Archive TestMemoryLeak2_A.zip    
Issue Links:
Dependency
depends on GLASSFISH-16917 Classloader leak in Glassfish 3.1 wit... Resolved
Tags: 3_1_1-scrubbed

 Description   

When I deploy this sample application 1000 times, I get MaxPerm leak and Heap does not look right either
The sample includes a basic JSF page, and beans.xml

Methodology
1) Unpack clean Glassfish 3.1
2) Copy WAR file to Glasfish home
3) start Glassfish
4) Run shell script loop.sh (shell)
5) wait for 1000 deploys

This issue is the first sample associated with http://java.net/jira/browse/GLASSFISH-16604



 Comments   
Comment by rjdkolb [ 16/May/11 ]

Add loop script

Comment by Sanjeeb Sahoo [ 16/May/11 ]

Assigning to CDI engineer to look into it.

Comment by rjdkolb [ 13/Jun/11 ]

Lookes better in 3.1.1 b7
Did the same test, see attached image

Comment by rjdkolb [ 13/Jun/11 ]

Looks better in 3.1.1 b7
See image

Comment by kshitiz_saxena [ 30/Jun/11 ]

The further investigation of memory leaks shows WebappClassLoader being held across redeploy.

The reference of WebappClassLoader is provided below :
Class Name | Shallow Heap | Retained Heap
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
org.glassfish.web.loader.WebappClassLoader @ 0x7e11681e8 | 328 | 159,832
'- classLoader com.sun.enterprise.deployment.WebBundleDescriptor @ 0x7e1a9bd48 | 496 | 61,320
'- webBundleDescriptor com.sun.enterprise.web.WebModule @ 0x7e1b817e8 | 1,064 | 52,552
'- context org.apache.catalina.core.ApplicationContext @ 0x7e1b7fb68 | 64 | 73,624
'- context org.apache.catalina.core.ApplicationContextFacade @ 0x7e19a78b8 | 32 | 73,872
'- servletContext com.sun.faces.config.InitFacesContext$ServletContextAdapter @ 0x7e199ece8 | 48 | 73,984
'- ec com.sun.faces.config.InitFacesContext @ 0x7e0e0aea0 | 96 | 344,992
'- orig com.sun.faces.config.InitFacesContext @ 0x7e2429ec8 | 96 | 689,992
'- orig com.sun.faces.config.InitFacesContext @ 0x7e22991f8 | 96 | 1,035,016
'- orig com.sun.faces.config.InitFacesContext @ 0x7e225ecb8 | 96 | 1,380,056
'- orig com.sun.faces.config.InitFacesContext @ 0x7e31f61e8 | 96 | 1,725,088
'- orig com.sun.faces.config.InitFacesContext @ 0x7e232e358 | 96 | 2,070,136
'- orig com.sun.faces.config.InitFacesContext @ 0x7e301c240 | 96 | 2,415,160
'- orig com.sun.faces.config.InitFacesContext @ 0x7e3abdc88 | 96 | 2,760,144
'- orig com.sun.faces.config.InitFacesContext @ 0x7e38eaf50 | 96 | 3,105,160
'- orig com.sun.faces.config.InitFacesContext @ 0x7e3c6cb50 | 96 | 3,450,168
'- value java.lang.ThreadLocal$ThreadLocalMap$Entry @ 0x7e1be0f78 | 56 | 3,450,224
'- [83] java.lang.ThreadLocal$ThreadLocalMap$Entry[256] @ 0x7e2b91cd0 | 2,072 | 3,497,112
'- table java.lang.ThreadLocal$ThreadLocalMap @ 0x7e1bc8820 | 32 | 3,497,144
'- threadLocals com.sun.grizzly.http.HttpWorkerThread @ 0x7e1881da0 admin-thread-pool-4848(5) Thread| 272 | 3,597,264
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

So InitFacesContext is not released correctly, resulting in leak of WebappClassLoader. This issue will be fixed as part of 16917.

Comment by kshitiz_saxena [ 30/Jun/11 ]

Marking this issue as being dependent on 16917.

Comment by kshitiz_saxena [ 08/Jul/11 ]

Images of old and perm gen taken after issue GLASSFISH-16917 is fixed.

Comment by kshitiz_saxena [ 08/Jul/11 ]

This issue is also fixed with the resolution of issue GLASSFISH-16917.

The perm-gen and old-gen images attached to the bug shows that after a full GC, the perm-gen as well as old-gen does come down to a stable state. The stable state is close to non-cdi scenario.

Comment by rjdkolb [ 08/Jul/11 ]

Very nice, thank you.
Will test in 3.1.1 b11 and report back.

Comment by Sivakumar Thyagarajan [ 17/Oct/11 ]

Reopening issue to mark fix version

Comment by Sivakumar Thyagarajan [ 17/Oct/11 ]

Marked fix version as 3.1.1

Comment by Sivakumar Thyagarajan [ 17/Oct/11 ]

Marking resolution back as fixed





[GLASSFISH-16196] @OSGIService causes ClassCastException in OSGiServiceFactory$StaticInvocationHandler or OSGiServiceFactory.lookupService Created: 11/Mar/11  Updated: 17/Oct/11  Resolved: 23/Jun/11

Status: Resolved
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: 3.1
Fix Version/s: 3.1.1

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

Ubuntu 10.10, x64


Tags: 3_1_1-review, 3_1_1-scrubbed, cdi, osgi-javaee

 Description   

Given the following code snippet:

@WebService(targetNamespace="http://www.asml.com/otas/data-manager")
@SOAPBinding(parameterStyle=ParameterStyle.WRAPPED, style=Style.DOCUMENT, use=Use.LITERAL)
public class DataManagerWebService {

@Inject
@OSGiService(dynamic=true)
DataManager dataManagerService;
...
}

DataManager is defined in another bundle deployed succesfully on GlassFish.

In case I deploy the WAR containing the above JAX-WS web service classas an OSGi bundle, injection works as expected.

In case I deploy the WAR as a non-OSGi bundle (i.e. just as a regular WAR), I get class cast exceptions. This is both when using dynamic=true or dynamic=false, though the place where the exception occurs differs. See the stack traces below.

Expected behaviour: injection of OSGi Services should work transparent for both OSGi and non-OSGI WAR bundles. Though untested, I presume the same issue is present for e.g EJB and Servlet components.

Impact: high. We work from an Eclipse environment, where deploying OSGi bundles on a standard Glassfish container is not yet possible given the default Eclipse-Glassfish plugin. Being able to deploy OSGi WARs as regular WARs would greatly alleviate this short-comming. Glassfish is currently being evaluated as a future platform for migration (from Tomcat). Seamless OSGi/JavaEE integration is a high-priority requirement for us.

dynamic=true stacktrace:

[#|2011-03-11T17:48:33.439+0100|SEVERE|glassfish3.1|com.sun.xml.ws.server.sei.EndpointMethodHandler|_ThreadID=20;_ThreadName=Thread-1;|The log message is null.
java.lang.ClassCastException
at java.lang.Class.cast(Class.java:2990)
at org.glassfish.osgicdi.impl.OSGiServiceFactory.lookupService(OSGiServiceFactory.java:110)
at org.glassfish.osgicdi.impl.OSGiServiceFactory.access$100(OSGiServiceFactory.java:67)
at org.glassfish.osgicdi.impl.OSGiServiceFactory$DynamicInvocationHandler.invoke(OSGiServiceFactory.java:183)
at $Proxy264.deleteDocument(Unknown Source)
at com.asml.de.otas.dama.webservice.DataManagerWebService.deleteDocument(DataManagerWebService.java:58)
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.glassfish.webservices.InstanceResolverImpl$1.invoke(InstanceResolverImpl.java:143)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:150)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:261)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
...

dynamic=false stacktrace:

Caused by: java.lang.ClassCastException
at java.lang.Class.cast(Class.java:2990)
at org.glassfish.osgicdi.impl.OSGiServiceFactory$StaticInvocationHandler.getBundleContext(OSGiServiceFactory.java:212)
at org.glassfish.osgicdi.impl.OSGiServiceFactory$StaticInvocationHandler.<init>(OSGiServiceFactory.java:206)
at org.glassfish.osgicdi.impl.OSGiServiceFactory.createServiceProxy(OSGiServiceFactory.java:90)
at org.glassfish.osgicdi.impl.OSGiServiceFactory.getService(OSGiServiceFactory.java:79)
at org.glassfish.osgicdi.impl.OSGiServiceExtension$OSGiServiceBean.create(OSGiServiceExtension.java:242)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:67)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:690)
....



 Comments   
Comment by Sanjeeb Sahoo [ 01/May/11 ]

OSGiService qualifier is only available in the context of OSGi aware Java EE applications, not for plain Java EE applications. You seem to be already aware of this. From your description of the bug, it appears that you are looking for more transparent handling of depoyment of OSGi aware Java EE applications. If you can tell us a bit more about your development environment, we will be happy to work with you to see if we can use existing tools to address your concern.

Thanks much,
Sahoo

Comment by jbenckhuijsen [ 03/May/11 ]

Hi Sahoo,

I think there are three issues:

1) The code shouldn't throw a class cast exception, but something of a IllegalStateException. Indeed I'm aware of the limitations, however not everybody may be, so throwing a descriptive exception is a bit nicer. Minor priority.
2) Reason for this setup: mainly caused by the limitations of Eclipse Glassfish plugin not being able to deploy OSGi modules. So, right now, this could have been a workaround. for an issue which should be fixed elsewhere.
3) Future feature request: from a programmer point-of-view, why would it matter whether the client is a bundle or regular WAR? Is access to the OSGi ServiceLocator not possible from a Java EE context?

Thanks.

Jeroen

Comment by Sanjeeb Sahoo [ 03/May/11 ]

Hi Jeroen,

Thanks for taking time to respond. See my replies:

1) I will keep this bug open to see if we can improve the exception part as suggested by you.

2) When I have time, I want to investigate possibility of using Eclipse Libra project together with GlassFish, so that may solve this problem. But, better to have a discussion. Would you mind starting a separate forum thread (users@glassfish.java.net) to see how we can address the OSGi bundle deployment issue in Eclipse GlassFish plugin?

3) No, it is not possible to support OSGiService from a pure EE context, as it requires access to BundleContext. Many people tend to suggest using some arbitrary bundleContext to consume services, but modularity is also about knowing who can consume a service and identifying them in a runtime.

Sahoo

Comment by jbenckhuijsen [ 10/May/11 ]

Hi Sanjeeb,

1) Great!
2) Sent the mail today
3) Agreed

Cheers,

Jeroen

Comment by Sanjeeb Sahoo [ 10/May/11 ]

Can you send me a link to the email you sent to the alias? I don't see it.

Comment by jbenckhuijsen [ 11/May/11 ]

Mail was held for review as I was not subscribed yet, now online: http://www.java.net/forum/topic/glassfish/glassfish/eclipseglassfish-deployment-osgi-bundles

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

Analysis: In OSGiServiceFactory, we do not handle the scenario where the annotated injection point is in a non-OSGi bundle(regular WAR). So, in 3.1.1, at a minimum we should investigate modifying the error message to indicate that injection is attempted in a non-OSGi bundle.

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

Component Name: OSGi-CDI
Issue: http://java.net/jira/browse/GLASSFISH-16196

  • Why fix this issue in 3.1.1?

Affects scenarios where a OSGi/CDI injection is expected on a non-OSGi archive. Please see bug report for more information.

  • Which is the targeted build of 3.1.1 for this fix?

3.1.1 b08

  • Do regression tests exist for this issue?

I will add a regression test to the CDI developer test suite.

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

Regression test added to the CDI developer test suite.

Comment by Sivakumar Thyagarajan [ 22/Jun/11 ]

Fix checked in FighterFish as part of

Sending osgi-cdi/src/main/java/org/glassfish/osgicdi/impl/OSGiServiceExtension.java
Sending osgi-cdi/src/main/java/org/glassfish/osgicdi/impl/OSGiServiceFactory.java
Transmitting file data ..
Committed revision 47617.

Will mark as committed when the next version of FighterFish is integrated into 3.1.1 and trunk.

Comment by Sivakumar Thyagarajan [ 23/Jun/11 ]

Integrated org.glassfish.fighterfish:osgi-cdi 1.0.1 to trunk (svn rev 47637) and 3.1.1(svn rev 47636) to fix this issue.

Comment by Sivakumar Thyagarajan [ 17/Oct/11 ]

Marked fix version as 3.1.1





[GLASSFISH-16318] Overzealous class scanning Created: 06/Apr/11  Updated: 17/Oct/11  Resolved: 22/Jun/11

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

Type: Bug Priority: Major
Reporter: Jozef Hartinger Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File GLASSFISH-16318.patch     File test.war    
Tags: 3_1_1-approved, 3_1_1-scrubbed

 Description   

Having two CDI Beans:

public class ClassUnavailableAtRuntime {}

public class OptionalService extends ClassUnavailableAtRuntime {}

A deployment of a web application that bundles OptionalService but does not bundle ClassUnavailableAtRuntime fails, although the OptionalService is not used.

What should actually happen is that the ClassNotFoundException should be suppressed by the deployer and the OptionalService should not be registered as a CDI bean, instead of failing the entire deployment.

[#|2011-04-06T15:49:12.785+0200|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=58;_ThreadName=Thread-1;|Exception while loading the app : org/jboss/seam/compat/scanning/ClassUnavailableAtRuntime
java.lang.ClassNotFoundException: org.jboss.seam.compat.scanning.ClassUnavailableAtRuntime
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1518)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at org.glassfish.web.loader.WebappClassLoader.findClass(WebappClassLoader.java:925)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1485)
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
at org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:340)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:148)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:128)
at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:120)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:334)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:202)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:195)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:331)
at org.glassfish.admin.rest.resources.TemplateListOfResource.post(TemplateListOfResource.java:190)
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.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:186)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:70)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:279)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:86)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:74)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1347)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1279)
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:177)
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: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)

#]


 Comments   
Comment by Jozef Hartinger [ 06/Apr/11 ]

Test application source code https://github.com/seam/compatibility/tree/master/src/test/java/org/jboss/seam/compat/scanning

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

Attached an initial patch to fix this issue

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

In BeanDeploymentArchiveImpl.populate, we were eagerly evaluating the linkage and loadable nature of every Bean in the BDA. In the scenario discussed in this issue, this eager evaluation caused the deployment to fail. Fix involves ignoring Beans that cannot be loaded.

Comment by Sivakumar Thyagarajan [ 13/Jun/11 ]

Component Name: OSGi-CDI
Issue: http://java.net/jira/browse/GLASSFISH-16318

  • Why fix this issue in 3.1.1?

Affects CDI bean archives which have some Bean classes that cannot be loaded.

  • Which is the targeted build of 3.1.1 for this fix?

3.1.1 b08

  • Do regression tests exist for this issue?

Yes, the test included in this bug report. I will also add a developer test in the CDI devtests suite to cover this optional unbundled beans scenario.

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

The test included in this issue and the optional-unbundled-beans test in the CDI developer test suite.

Comment by Sivakumar Thyagarajan [ 22/Jun/11 ]

Fixed in 3.1.1 as part of svn commit 47614 and in trunk as part of svn commit 47615

Comment by Sivakumar Thyagarajan [ 17/Oct/11 ]

Marked fix version as 3.1.1





[GLASSFISH-10926] [BLOCKING] ejb lookup failed on aix Created: 09/Nov/09  Updated: 17/Oct/11  Resolved: 31/May/11

Status: Resolved
Project: glassfish
Component/s: naming
Affects Version/s: v2.1.1
Fix Version/s: 3.1.1, 3.1.2

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

Operating System: Linux
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 10,926
Status Whiteboard:

v3_exclude, 3.1-exclude

Tags: 3_1-exclude

 Description   

OS: AIX machine
build: V2.1.1
JDK version: IBM jdk1.6 + IBM patch for issue 6836 fix

aixas5(aroot):as911_ws/appserver-sqe -> /usr/java6/bin/java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap3260sr5-20090529_04(SR5))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 AIX ppc-32
jvmap3260sr5-20090519_35743 (JIT enabled, AOT enabled)
J9VM - 20090519_035743_bHdSMr
JIT - r9_20090518_2017
GC - 20090417_AA)
JCL - 20090529_01

After applying the IBM patch, we no longer saw errors that reported in issue
6836. However, all the test cases using ejb lookup in the SQE core modules are
still failed. The issue blocked Core testing on AIX.

Steps to reproduce the bug:
1. Install V2.1.1. start domain
2. Checkout SQE workspace:
cvs co -r SJSAS911_FCS_BRANCH appserver-sqe/bootstrap.xml
(CVSROOT: :pserver:<user>@redcvs.red.iplanet.com:/m/jws)
cd appserver-sqe
ant -f bootstrap.xml -Dtag=SJSAS911_FCS_BRANCH co-security
3.set env. variables
S1AS_HOME <AS install dir>
SPS_HOME <appserver-sqe>
ANT_HOME <ant 1.6.5>
JAVA_HOME <jdk1.6.0_16>
4. open file appserver-sqe/pe/config.properties, update right path and ports to
match your AS installation data (for example: admin password, http port, admin
port...)
5. cd appserver-sqe/pe/security/authoriz/methodperms, run "ant build setup
deploy run", the test failed with the following error:
runclient-common:
[echo] Executing appclient at
/export/homer/as911_ws/appserver-sqe/pe/security/authoriz/methodperms
[echo] WS HOME appserver-sqe
[echo] -->EJB method permissions!javax.naming.NameNotFoundException:
??MyMethodPerm not found
[echo] at
?com.sun.enterprise.naming.TransientContext.?doLookup(?TransientContext.java:216)
[echo] at
?com.sun.enterprise.naming.TransientContext.?lookup(?TransientContext.java:188)
[echo] at
?com.sun.enterprise.naming.SerialContextProviderImpl.?lookup(?SerialContextProviderImpl.java:74)
[echo] at
?com.sun.enterprise.naming.RemoteSerialContextProviderImpl.?lookup(?RemoteSerialContextProviderImpl.java:129)
[echo] at ?sun.reflect.NativeMethodAccessorImpl.?invoke0(Native Method)
[echo] at
?sun.reflect.NativeMethodAccessorImpl.?invoke(?NativeMethodAccessorImpl.java:39)
[echo] at
?sun.reflect.DelegatingMethodAccessorImpl.?invoke(?DelegatingMethodAccessorImpl.java:37)
[echo] at ?java.lang.reflect.Method.?invoke(?Method.java:599)
[echo] at
?com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.?_invoke(?ReflectiveTie.java:154)
[echo] at
?com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.?dispatchToServant(?CorbaServerRequestDispatcherImpl.java:687)
[echo] at
?com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.?dispatch(?CorbaServerRequestDispatcherImpl.java:227)
[echo] at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleRequestRequest(?CorbaMessageMediatorImpl.java:1846)
[echo] at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleRequest(?CorbaMessageMediatorImpl.java:1706)
[echo] at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleInput(?CorbaMessageMediatorImpl.java:1088)
[echo] at
?com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.?callback(?RequestMessage_1_2.java:223)
[echo] at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleRequest(?CorbaMessageMediatorImpl.java:806)
[echo] at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?dispatch(?CorbaMessageMediatorImpl.java:563)
[echo] at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?doWork(?CorbaMessageMediatorImpl.java:2567)
[echo] at
?com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.?run(?ThreadPoolImpl.java:555)
[echo] Calling authorized method - authorizedMethod
[echo] java.lang.NullPointerException
[echo] at
com.sun.s1peqe.security.authoriz.methodperms.MethodPermClient.doTest(MethodPermClient.java:69)
[echo] at
com.sun.s1peqe.security.authoriz.methodperms.MethodPermClient.main(MethodPermClient.java:28)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[echo] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[echo] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[echo] at java.lang.reflect.Method.invoke(Method.java:599)
[echo] at
com.sun.enterprise.util.Utility.invokeApplicationMain(Utility.java:266)
[echo] at
com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:450)
[echo] at
com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:260)
[echo] at com.sun.enterprise.appclient.Main.main(Main.java:200)
[echo] Test Failed
[echo] Calling unauthorized method - sayGoodBye
[echo] Calling unauthorized method - unauthorizedMethod
[echo] Nov 9, 2009 4:42:19 PM
com.sun.enterprise.appclient.MainWithModuleSupport <init>
[echo] WARNING: ACC003: Application threw an exception.
[echo] Throwable occurred: java.lang.NullPointerException
[echo] at
com.sun.s1peqe.security.authoriz.methodperms.MethodPermClient.doTest(MethodPermClient.java:107)
[echo] at
com.sun.s1peqe.security.authoriz.methodperms.MethodPermClient.main(MethodPermClient.java:28)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[echo] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[echo] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[echo] at java.lang.reflect.Method.invoke(Method.java:599)
[echo] at
com.sun.enterprise.util.Utility.invokeApplicationMain(Utility.java:266)
[echo] at
com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:450)
[echo] at
com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:260)
[echo] at com.sun.enterprise.appclient.Main.main(Main.java:200)
[echo] Exception in thread "main" java.lang.RuntimeException:
java.lang.reflect.InvocationTargetException
[echo] at
com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:462)
[echo] at
com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:260)
[echo] at com.sun.enterprise.appclient.Main.main(Main.java:200)
[echo] Caused by: java.lang.reflect.InvocationTargetException
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[echo] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[echo] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[echo] at java.lang.reflect.Method.invoke(Method.java:599)
[echo] at
com.sun.enterprise.util.Utility.invokeApplicationMain(Utility.java:266)
[echo] at
com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:450)
[echo] ... 2 more
[echo] Caused by: java.lang.NullPointerException
[echo] at
com.sun.s1peqe.security.authoriz.methodperms.MethodPermClient.doTest(MethodPermClient.java:107)
[echo] at
com.sun.s1peqe.security.authoriz.methodperms.MethodPermClient.main(MethodPermClient.java:28)
[echo] ... 8 more

There is no exceptions in server.log (server.log attached)



 Comments   
Comment by sonialiu [ 09/Nov/09 ]

Created an attachment (id=3834)
server.log

Comment by Ken Cavanaugh [ 09/Nov/09 ]

Why do you think this is an ORB bug? The ORB only appears to be the
messenger here. What is the NPE at the bottom of the stack in
com.sun.s1peqe.security.authoriz.methodperms.MethodPermClient.doTest?
Does this mean that something under test returned an unexpected null
pointer?

The only ORB code here is simply delivering an incoming request to
GlassFish naming, which is not part of the ORB. I'll re-assign this to
naming for lack of a better category.

Comment by sonialiu [ 09/Nov/09 ]

I was not sure which category i should choose for the bug. Since the client
outputs have a common exception "javax.naming.NameNotFoundException" and it
pointed to "com.sun.corba.ee.impl....", so I thought I should choose ORB
category. Appreciate if you could let me know which subcomponent this bug
belongs to. I will reassign it. Thanks.

Here are more client logs from deployment and ejb test modules:

client side log from deployment test module:------------------

runclient-common:
[echo] Executing appclient at
/export/homer/as911_ws/appserver-sqe/pe/deployment/stateless/helloworld
[echo] WS HOME appserver-sqe
Client: caught throwable
javax.naming.NameNotFoundException: ??helloworld not found
at
?com.sun.enterprise.naming.TransientContext.?doLookup(?TransientContext.java:216)
at ?com.sun.enterprise.naming.TransientContext.?lookup(?TransientContext.java:188)
at
?com.sun.enterprise.naming.SerialContextProviderImpl.?lookup(?SerialContextProviderImpl.java:74)
at
?com.sun.enterprise.naming.RemoteSerialContextProviderImpl.?lookup(?RemoteSerialContextProviderImpl.java:129)
at ?sun.reflect.GeneratedMethodAccessor94.?invoke(Unknown Source)
at
?sun.reflect.DelegatingMethodAccessorImpl.?invoke(?DelegatingMethodAccessorImpl.java:37)
at ?java.lang.reflect.Method.?invoke(?Method.java:599)
at
?com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.?_invoke(?ReflectiveTie.java:154)
at
?com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.?dispatchToServant(?CorbaServerRequestDispatcherImpl.java:687)
at
?com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.?dispatch(?CorbaServerRequestDispatcherImpl.java:227)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleRequestRequest(?CorbaMessageMediatorImpl.java:1846)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleRequest(?CorbaMessageMediatorImpl.java:1706)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleInput(?CorbaMessageMediatorImpl.java:1088)
at
?com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.?callback(?RequestMessage_1_2.java:223)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleRequest(?CorbaMessageMediatorImpl.java:806)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?dispatch(?CorbaMessageMediatorImpl.java:563)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?doWork(?CorbaMessageMediatorImpl.java:2567)
at
?com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.?run(?ThreadPoolImpl.java:555)

---- client side log from ejb test module -------------------
runclient-common:
[echo] Executing appclient at
/export/homer/as911_ws/appserver-sqe/pe/ejb/stateful/passivate
[echo] WS HOME appserver-sqe
Test Execution Starts---------->
Looking up SFSB0
Lookup of beans failed
javax.naming.NameNotFoundException: ??MySessionTest not found
at
?com.sun.enterprise.naming.TransientContext.?doLookup(?TransientContext.java:216)
at ?com.sun.enterprise.naming.TransientContext.?lookup(?TransientContext.java:188)
at
?com.sun.enterprise.naming.SerialContextProviderImpl.?lookup(?SerialContextProviderImpl.java:74)
at
?com.sun.enterprise.naming.RemoteSerialContextProviderImpl.?lookup(?RemoteSerialContextProviderImpl.java:129)
at ?sun.reflect.GeneratedMethodAccessor94.?invoke(Unknown Source)
at
?sun.reflect.DelegatingMethodAccessorImpl.?invoke(?DelegatingMethodAccessorImpl.java:37)
at ?java.lang.reflect.Method.?invoke(?Method.java:599)
at
?com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.?_invoke(?ReflectiveTie.java:154)
at
?com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.?dispatchToServant(?CorbaServerRequestDispatcherImpl.java:687)
at
?com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.?dispatch(?CorbaServerRequestDispatcherImpl.java:227)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleRequestRequest(?CorbaMessageMediatorImpl.java:1846)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleRequest(?CorbaMessageMediatorImpl.java:1706)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleInput(?CorbaMessageMediatorImpl.java:1088)
at
?com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.?callback(?RequestMessage_1_2.java:223)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?handleRequest(?CorbaMessageMediatorImpl.java:806)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?dispatch(?CorbaMessageMediatorImpl.java:563)
at
?com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.?doWork(?CorbaMessageMediatorImpl.java:2567)
at
?com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.?run(?ThreadPoolImpl.java:555)
Test didn't run

Comment by sherryshen [ 09/Nov/09 ]

change version from v3 to v2.1.1.

Comment by sonialiu [ 09/Nov/09 ]

correct product version. It should be v2.1.1.

Comment by kumara [ 09/Nov/09 ]

Excluding from v3, AIX is not supported for v3.

Comment by Nazrul [ 16/May/10 ]

Setting target milestone to 3.1

Comment by Cheng Fang [ 28/Jun/10 ]

Support for AIX platform will be added post 3.1 release.

Comment by Cheng Fang [ 31/May/11 ]

Confirmed with Sonia and Sherry that this issue is no longer present in 3.1.1 testing.





[GLASSFISH-16683] Catastrophe if monitoring is disabled Created: 18/May/11  Updated: 20/Sep/11  Resolved: 20/May/11

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

Type: Bug Priority: Blocker
Reporter: Byron Nevins Assignee: Mahesh Kannan
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-16675 Flashlight Agent Not Yet Working Resolved

 Description   

Brand new install of 3.1.1

edit domain.xml like so
<monitoring-service monitoring-enabled="false">

(you could also call 'asadmin disable-monitoring' on a running server)

Start DAS

KABOOM!! Catastrophe! See the first comment for the errors in the server.log

I tested this on JDK6 vs. 7 – it is unrelated. It fails horribly on both

My next test was on 3.2. Disabling monitoring on 3.2 has no bad effect.

I am assuming that this is caused by the btrace removal so I'm assigning it to Mahesh to investigate.



 Comments   
Comment by Byron Nevins [ 18/May/11 ]

As promised - here are the errors...

[#|2011-05-18T19:30:38.392-0700|SEVERE|oracle-glassfish3.1|org.apache.tomcat.util.modeler.Registry|_ThreadID=1;_ThreadName=main;|Error registering glassfish-web:type=Connector,port=8080,address=0.0.0.0
javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder: java.lang.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:502)
at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:538)
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:315)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:230)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:191)
at org.apache.tomcat.util.modeler.Registry.getMBeanServer(Registry.java:601)
at org.apache.tomcat.util.modeler.Registry.registerComponent(Registry.java:799)
at org.apache.catalina.connector.Connector.initialize(Connector.java:1288)
at com.sun.enterprise.web.connector.coyote.PECoyoteConnector.initialize(PECoyoteConnector.java:704)
at com.sun.enterprise.web.WebConnector.initialize(WebConnector.java:76)
at org.apache.catalina.startup.Embedded.start(Embedded.java:934)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:597)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:956)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:666)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:613)
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.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at java.net.URLClassLoader$1.run(URLClassLoader.java:299)
at java.net.URLClassLoader$1.run(URLClassLoader.java:288)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:287)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1535)
at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1472)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)
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:358)
at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:445)
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:487)
... 39 more

#]

[#|2011-05-18T19:30:38.398-0700|SEVERE|oracle-glassfish3.1|org.apache.catalina.connector.Connector|_ThreadID=1;_ThreadName=main;|Error registering connector
javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder: java.lang.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:502)
at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:538)
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:315)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:230)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:191)
at org.apache.tomcat.util.modeler.Registry.getMBeanServer(Registry.java:601)
at org.apache.tomcat.util.modeler.Registry.registerComponent(Registry.java:799)
at org.apache.catalina.connector.Connector.initialize(Connector.java:1288)
at com.sun.enterprise.web.connector.coyote.PECoyoteConnector.initialize(PECoyoteConnector.java:704)
at com.sun.enterprise.web.WebConnector.initialize(WebConnector.java:76)
at org.apache.catalina.startup.Embedded.start(Embedded.java:934)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:597)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:956)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:666)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:613)
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.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at java.net.URLClassLoader$1.run(URLClassLoader.java:299)
at java.net.URLClassLoader$1.run(URLClassLoader.java:288)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:287)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1535)
at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1472)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)
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:358)
at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:445)
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:487)
... 39 more

#]

[#|2011-05-18T19:30:38.418-0700|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=main;|Cannot start container web
javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder: java.lang.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:502)
at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:538)
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:315)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:230)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:191)
at com.sun.enterprise.web.connector.extension.GrizzlyConfig.<init>(GrizzlyConfig.java:129)
at com.sun.enterprise.web.connector.coyote.PECoyoteConnector.initialize(PECoyoteConnector.java:706)
at com.sun.enterprise.web.WebConnector.initialize(WebConnector.java:76)
at org.apache.catalina.startup.Embedded.start(Embedded.java:934)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:597)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:956)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:666)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:613)
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.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at java.net.URLClassLoader$1.run(URLClassLoader.java:299)
at java.net.URLClassLoader$1.run(URLClassLoader.java:288)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:287)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1535)
at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1472)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)
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:358)
at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:445)
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:487)
... 37 more

#]

[#|2011-05-18T19:30:38.421-0700|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=main;|Aborting, Failed to start container com.sun.enterprise.web.WebContainer|#]

[#|2011-05-18T19:30:38.422-0700|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=main;|Exception while deploying the app [hello]|#]

[#|2011-05-18T19:30:38.423-0700|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=main;|Aborting, Failed to start container com.sun.enterprise.web.WebContainer
java.lang.Exception: Aborting, Failed to start container com.sun.enterprise.web.WebContainer
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:669)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:613)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]

[#|2011-05-18T19:30:38.492-0700|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=main;|Exception while deploying the app [hello]|#]

[#|2011-05-18T19:30:38.499-0700|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=main;|Oracle GlassFish Server 3.1.1 (5) startup time : Felix (5,090ms), startup services(7,219ms), total(12,309ms)|#]

[#|2011-05-18T19:30:39.566-0700|INFO|oracle-glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=48;_ThreadName=Thread-25;|JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://improvident:8686/jndi/rmi://improvident:8686/jmxrmi|#]

Comment by Mahesh Kannan [ 20/May/11 ]

First of all, I am unable to reproduce this issue. I checked out and built a fresh 3.1.1 and set the monitoring-enabled="false". Then started the domain and the server started fine.

Also, I don't see anything related to flashlight in the stack trace. It is complaining about AppServerMBeanServerBuilder. So, I am not sure how this is related to the recent monitoring changes.

Assigning this to Byron. Byron: Clo

Comment by Byron Nevins [ 20/May/11 ]

Mahesh says it is invalid. Reassigning to him and marking it as such

Comment by Byron Nevins [ 20/May/11 ]

Reported as non reproducible.

Comment by yourib39 [ 12/Sep/11 ]

I had the same issue and had to reactivate monitoring to get my instance to start

Comment by Scott101011 [ 20/Sep/11 ]

I'm also running into this issue. I can start/re-start the domain without monitoring as long as I have no deployed applications. Once I deploy applications a domain restart results in the errors listed above.

I've tested this in 3 separate environments, Win32, Win64, RHEL 5.5 32Bit. They all exhibit the same behavior upon restart of a domain with deployed applications and SSL enabled.

If I disable SSL or enable monitoring the domain starts without issue.

Log snippet below:

[#|2011-09-20T14:43:03.291+0000|SEVERE|glassfish3.1|org.apache.tomcat.util.modeler.Registry|_ThreadID=1;_ThreadName=Thread-1;|Error registering glassfish-web:type=Connector,port=80,address=0.0.0.0
javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder: java.lang.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:502)
at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:538)
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:315)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:230)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:191)
at org.apache.tomcat.util.modeler.Registry.getMBeanServer(Registry.java:594)
at org.apache.tomcat.util.modeler.Registry.registerComponent(Registry.java:792)
at org.apache.catalina.connector.Connector.initialize(Connector.java:1322)
at com.sun.enterprise.web.connector.coyote.PECoyoteConnector.initialize(PECoyoteConnector.java:704)
at com.sun.enterprise.web.WebConnector.initialize(WebConnector.java:76)
at org.apache.catalina.startup.Embedded.start(Embedded.java:934)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:584)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:955)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:665)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1535)
at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1472)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)
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:356)
at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:445)
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:487)
... 39 more

#]

[#|2011-09-20T14:43:03.293+0000|SEVERE|glassfish3.1|org.apache.catalina.connector.Connector|_ThreadID=1;_ThreadName=Thread-1;|Error registering connector
javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder: java.lang.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:502)
at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:538)
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:315)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:230)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:191)
at org.apache.tomcat.util.modeler.Registry.getMBeanServer(Registry.java:594)
at org.apache.tomcat.util.modeler.Registry.registerComponent(Registry.java:792)
at org.apache.catalina.connector.Connector.initialize(Connector.java:1322)
at com.sun.enterprise.web.connector.coyote.PECoyoteConnector.initialize(PECoyoteConnector.java:704)
at com.sun.enterprise.web.WebConnector.initialize(WebConnector.java:76)
at org.apache.catalina.startup.Embedded.start(Embedded.java:934)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:584)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:955)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:665)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1535)
at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1472)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)
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:356)
at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:445)
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:487)
... 39 more

#]

[#|2011-09-20T14:43:03.355+0000|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-1;|Cannot start container web
javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder: java.lang.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:502)
at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:538)
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:315)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:230)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:191)
at com.sun.enterprise.web.connector.extension.GrizzlyConfig.<init>(GrizzlyConfig.java:129)
at com.sun.enterprise.web.connector.coyote.PECoyoteConnector.initialize(PECoyoteConnector.java:706)
at com.sun.enterprise.web.WebConnector.initialize(WebConnector.java:76)
at org.apache.catalina.startup.Embedded.start(Embedded.java:934)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:584)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:955)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:665)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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.ClassNotFoundException: com.sun.enterprise.v3.admin.AppServerMBeanServerBuilder
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1535)
at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1472)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)
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:356)
at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:445)
at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:487)
... 37 more

#]

[#|2011-09-20T14:43:03.356+0000|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-1;|Aborting, Failed to start container com.sun.enterprise.web.WebContainer|#]

[#|2011-09-20T14:43:03.356+0000|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-1;|Exception while deploying the app [ProxyServices]|#]

[#|2011-09-20T14:43:03.356+0000|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-1;|Aborting, Failed to start container com.sun.enterprise.web.WebContainer
java.lang.Exception: Aborting, Failed to start container com.sun.enterprise.web.WebContainer
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:668)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]

[#|2011-09-20T14:43:03.568+0000|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-1;|Exception while deploying the app [ProxyServices]|#]

[#|2011-09-20T14:43:13.895+0000|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=1;_ThreadName=Thread-1;|WEB0169: Created HTTP listener [http-listener-1] on host/port [0.0.0.0:80]|#]

[#|2011-09-20T14:43:13.899+0000|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=1;_ThreadName=Thread-1;|WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:443]|#]

[#|2011-09-20T14:43:13.904+0000|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=1;_ThreadName=Thread-1;|WEB0169: Created HTTP listener [admin-listener] on host/port [0.0.0.0:4848]|#]

[#|2011-09-20T14:43:13.914+0000|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=1;_ThreadName=Thread-1;|WEB0171: Created virtual server [server]|#]

[#|2011-09-20T14:43:13.916+0000|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=1;_ThreadName=Thread-1;|WEB0171: Created virtual server [__asadmin]|#]

[#|2011-09-20T14:43:13.917+0000|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=1;_ThreadName=Thread-1;|WEB0172: Virtual server [server] loaded default web module [null]|#]

[#|2011-09-20T14:43:13.936+0000|SEVERE|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=1;_ThreadName=Thread-1;|WEB0122: Unable to start web container
org.apache.catalina.LifecycleException: PWC3042: Embedded service has already been started
at org.apache.catalina.startup.Embedded.start(Embedded.java:926)
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:584)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:955)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:684)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]




[GLASSFISH-15883] Many-to-many join table not updated Created: 08/Feb/11  Updated: 24/Aug/11  Resolved: 24/Aug/11

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: v3.0.1
Fix Version/s: 3.1.1

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

Ubuntu Linux, WinXP, MySql 5.1


Attachments: Zip Archive foobar.zip     Zip Archive gfbug-15883-tickler-v2.zip     Zip Archive gfbug-15883-tickler.zip     Zip Archive gfbug-15883.zip     Zip Archive Issue15883.zip     File server.log.0511    
Tags: 3-1_exclude, 3_1_1-scrubbed, JPA, many-to-many

 Description   

A business method in a @Stateless EJB that first removes all many-to-many relations for an entity (Bar) to another entity (Foo), and then immediately adds several new many-to-many realations for the same entity, leaves no rows for the new relations in the join table.

Everything is called from a web application. In the webapp everything looks correct, so I presume that the cached data is correct, but the JPA database update has failed. (So the relations are gone after a redeploy or restart).

This happens only if the related entity (Foo) has a key of type String/CHAR(5), not int.

I have managed to isolate the problem into a minimalistic set of source files. The offending call in the attached code example is flummox(barId);

This looks like a bug to me. Hope I haven't just done something silly. I'll be happy to provide further details, as needed.



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

I am not able to reproduce the issue using attached reproduction on 3.1 nightly. The reproduction ties to use entities provided by you and the logic provided by you in EJB. It does not use the sql script provided by you but uses java2db and @Column to create a CHAR column

Here are steps to exercise the test:
1. start derby executing "asadmin start-database"
2. start v3
3. unzip and deploy build/basicwebapp.war. This will create tables
4. Goto http://gfhost:gfport/basicwebapp/test?operation=createData. This creates initial data in databsae
5. Goto http://gfhost:gfport/basicwebapp/test?operation=updateData. This updates data using logic provided by you in EJB

You can see the executed SQL in server.log for both the steps above and verify that relationships are persisted at update.

Comment by Mitesh Meswani [ 08/Feb/11 ]

Closing this as "Cannot Reproduce". If you are able to reproduce the issue, please adapt the test case in Issue15883.zip for reproduction steps and reopen this issue.

Comment by tmpsa [ 09/Feb/11 ]

I ran your test case on my 3.0.1 Glassfish server, and it works fine. So it does not reproduce the problem on GF 3.0.1. So we can't say that the problem is gone in Glassfish 3.1.

Further efforts to reproduce the problem is needed.

Comment by Mitesh Meswani [ 09/Feb/11 ]

>Further efforts to reproduce the problem is needed
Agree. Can you please work on modifying the test case so that we can get it reproduced and analyzed.

Thanks,
Mitesh

Comment by tmpsa [ 16/Feb/11 ]

I have now spent some additional hours to create a reproducible case. The uploaded zip archive contains a complete EAR that reproduces the problem. It requires MySql, hope that's not a problem for you.

1. Run the SQL script to create the database.
2. Do "%SJSAS_HOME%\bin\asadmin add-resources glassfish-mysql-ds.xml" to set up the connection pool.
3. Build the webapp with 'ant dist'
4. Deploy
5. Browse to .../gfbug
6. Follow the instructions;
6a. Create data
6b. Add all relations
6c. Tickle the bug
7. See server.log for SQL trace. If the bug is tickled, 6c. should result in only DELETE statements.

I really hope this helps you find the bug.

I'm not allowed to reopen this issue myself, please do it.

Comment by Mitesh Meswani [ 17/Feb/11 ]

Thanks for a more details test case. I am still not able to see the issue though. [1] is from server.log of my run with the test case that demonstrates that sqls are executed as expected.
Please note that I have done following modification to the test. None of which should affect the behvaior
1. Added @Column(columnDefinition = " char(5)") to Foo to enable java2db
2. I am running the test against javadb instead of MySQL
3. Added the debug statement with "***" to the servlet code to demark operations

[1] server.log snippet.

[#|2011-02-17T18:34:47.955-0800|INFO|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9|_ThreadID=18;_ThreadName=Thread-1;|file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9 login successful|#]
[#|2011-02-17T18:34:48.938-0800|INFO|glassfish3.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=80;_ThreadName=Thread-1;|Portable JNDI names for EJB FoobarEjb : [java:global/gfbug/gfbug-ejb/FoobarEjb!com.yoyodyne.ejbs.FoobarLocal, java:global/gfbug/gfbug-ejb/FoobarEjb]|#]
[#|2011-02-17T18:34:49.063-0800|INFO|glassfish3.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=80;_ThreadName=Thread-1;|WEB0671: Loading application gfbug#gfbug.war at [gfbug]|#]
[#|2011-02-17T18:34:49.094-0800|INFO|glassfish3.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=80;_ThreadName=Thread-1;|gfbug was successfully deployed in 2,200 milliseconds.|#]
[#|2011-02-17T18:34:56.165-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=23;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO foo (ID, NAME) VALUES (?, ?)
bind => [11111, foo1]|#]
[#|2011-02-17T18:34:56.171-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=23;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO foo (ID, NAME) VALUES (?, ?)
bind => [22222, foo2]|#]
[#|2011-02-17T18:34:56.174-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=23;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO foo (ID, NAME) VALUES (?, ?)
bind => [33333, foo3]|#]
[#|2011-02-17T18:34:56.177-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=23;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO bar (NAME) VALUES
bind => [bar1]|#]
[#|2011-02-17T18:34:56.181-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=23;_ThreadName=Thread-1;ClassName=null;MethodName=null;|values IDENTITY_VAL_LOCAL()|#]
[#|2011-02-17T18:34:56.183-0800|INFO|glassfish3.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=104;_ThreadName=Thread-1;|********************Done executing operation:createData *********************|#]
[#|2011-02-17T18:35:55.097-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=24;_ThreadName=Thread-1;ClassName=null;MethodName=null;|SELECT ID, NAME FROM foo|#]
[#|2011-02-17T18:35:55.104-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=24;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO foo_bar (bar_id, foo_id) VALUES (?, ?)
bind => [1, 22222]|#]
[#|2011-02-17T18:35:55.109-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=24;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO foo_bar (bar_id, foo_id) VALUES (?, ?)
bind => [1, 33333]|#]
[#|2011-02-17T18:35:55.110-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=24;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO foo_bar (bar_id, foo_id) VALUES (?, ?)
bind => [1, 11111]|#]
[#|2011-02-17T18:35:55.112-0800|INFO|glassfish3.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=106;_ThreadName=Thread-1;|********************Done executing operation:addAll *********************|#]
[#|2011-02-17T18:36:06.253-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=27;_ThreadName=Thread-1;ClassName=null;MethodName=null;|DELETE FROM foo_bar WHERE ((bar_id = ?) AND (foo_id = ?))
bind => [1, 22222]|#]
[#|2011-02-17T18:36:06.253-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=27;_ThreadName=Thread-1;ClassName=null;MethodName=null;|DELETE FROM foo_bar WHERE ((bar_id = ?) AND (foo_id = ?))
bind => [1, 33333]|#]
[#|2011-02-17T18:36:06.253-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=27;_ThreadName=Thread-1;ClassName=null;MethodName=null;|DELETE FROM foo_bar WHERE ((bar_id = ?) AND (foo_id = ?))
bind => [1, 11111]|#]
[#|2011-02-17T18:36:06.253-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=27;_ThreadName=Thread-1;ClassName=null;MethodName=null;|SELECT ID, NAME FROM foo|#]
[#|2011-02-17T18:36:06.270-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=27;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO foo_bar (bar_id, foo_id) VALUES (?, ?)
bind => [1, 22222]|#]
[#|2011-02-17T18:36:06.272-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=27;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO foo_bar (bar_id, foo_id) VALUES (?, ?)
bind => [1, 33333]|#]
[#|2011-02-17T18:36:06.273-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=27;_ThreadName=Thread-1;ClassName=null;MethodName=null;|INSERT INTO foo_bar (bar_id, foo_id) VALUES (?, ?)
bind => [1, 11111]|#]
[#|2011-02-17T18:36:06.276-0800|INFO|glassfish3.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=107;_ThreadName=Thread-1;|********************Done executing operation:flummox *********************|#]
[#|2011-02-17T18:36:31.924-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=19;_ThreadName=Thread-1;ClassName=null;MethodName=null;|DELETE FROM foo_bar WHERE ((bar_id = ?) AND (foo_id = ?))
bind => [1, 22222]|#]
[#|2011-02-17T18:36:31.926-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=19;_ThreadName=Thread-1;ClassName=null;MethodName=null;|DELETE FROM foo_bar WHERE ((bar_id = ?) AND (foo_id = ?))
bind => [1, 33333]|#]
[#|2011-02-17T18:36:31.928-0800|FINE|glassfish3.2|org.eclipse.persistence.session.file:/C:/work/v3/publish/glassfish3/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=19;_ThreadName=Thread-1;ClassName=null;MethodName=null;|DELETE FROM foo_bar WHERE ((bar_id = ?) AND (foo_id = ?))
bind => [1, 11111]|#]
[#|2011-02-17T18:36:31.931-0800|INFO|glassfish3.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=108;_ThreadName=Thread-1;|********************Done executing operation:removeAll *********************|#]

Comment by tmpsa [ 18/Feb/11 ]

This is an elusive bug indeed! I have already noted at an earlier stage that it's a slippery fellow; if I change something seemingly irrelevant, the bug does not appear. Therefore I'm so happy that I have managed to contain it in a reproducible self-contained webapp.

Could you please run the test case exactly as it is, without any modification or shortcuts, on Glassfish 3.0.1 and MySql? That should show you the bug.

Comment by tmpsa [ 10/May/11 ]

I have now upgraded to the Glassfish 3.1 release.

I re-ran my test app, and the error remains.

For the EJB method 'flummox()' the log file shows the three "DELETE FROM foo_bar ..." statements, and the following "SELECT ... FROM foo", but not any "INSERT INTO foo_bar ..."!

Please run my test app without any modifications! It should show you the same result as I get. Then please re-open this issue!

Comment by tmpsa [ 10/May/11 ]

I just noted something interesting. If you switch the JPA "owning side" from entity Foo to entity Bar (and make Foo the inverse side), then the bug goes into hiding.
Hope this helps in narrowing it down a bit.

Comment by tmpsa [ 10/May/11 ]

See read-me.txt for instructions

Comment by tmpsa [ 10/May/11 ]

I have now uploaded a slightly updated version of my test app. See the file read-me.txt for instructions. The problem also exists in our production application, and is 100% reproducible.

Here follows the output in server.xml from a test run on GF3.1 on my WinXP box. When playing around with the functions "Add relations" and "Remove relations" one may note that the SQL statements are executed after the EJB method is done. In the specific test case 'flummox', the DELETE SQL statements are executed in 'add all Foos', and no INSERT SQL statement are ever executed.

--snip--

[#|2011-05-10T14:41:03.609+0200|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=83;_ThreadName=Thread-1;|--- begin flummox ---|#]

[#|2011-05-10T14:41:03.609+0200|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=83;_ThreadName=Thread-1;|--- begin remove all Foos ---|#]

[#|2011-05-10T14:41:03.609+0200|FINE|glassfish3.1|org.eclipse.persistence.session.file:/C:/Program Files/Glassfish/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|SELECT t1.ID, t1.NAME FROM foo_bar t0, foo t1 WHERE ((t0.bar_id = ?) AND (t1.ID = t0.foo_id))
bind => [1]|#]

[#|2011-05-10T14:41:03.609+0200|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=83;_ThreadName=Thread-1;|--- end remove all Foos ---|#]

[#|2011-05-10T14:41:03.625+0200|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=83;_ThreadName=Thread-1;|--- begin add all Foos ---|#]

[#|2011-05-10T14:41:03.625+0200|FINE|glassfish3.1|org.eclipse.persistence.session.file:/C:/Program Files/Glassfish/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|DELETE FROM foo_bar WHERE ((bar_id = ?) AND (foo_id = ?))
bind => [1, 22222]|#]

[#|2011-05-10T14:41:03.625+0200|FINE|glassfish3.1|org.eclipse.persistence.session.file:/C:/Program Files/Glassfish/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|DELETE FROM foo_bar WHERE ((bar_id = ?) AND (foo_id = ?))
bind => [1, 33333]|#]

[#|2011-05-10T14:41:03.625+0200|FINE|glassfish3.1|org.eclipse.persistence.session.file:/C:/Program Files/Glassfish/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|DELETE FROM foo_bar WHERE ((bar_id = ?) AND (foo_id = ?))
bind => [1, 11111]|#]

[#|2011-05-10T14:41:03.625+0200|FINE|glassfish3.1|org.eclipse.persistence.session.file:/C:/Program Files/Glassfish/glassfish/domains/domain1/applications/gfbug/gfbug-ejb_jar/_pu9.sql|_ThreadID=18;_ThreadName=Thread-1;ClassName=null;MethodName=null;|SELECT ID, NAME FROM foo|#]

[#|2011-05-10T14:41:03.625+0200|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=83;_ThreadName=Thread-1;|--- end add all Foos ---|#]

[#|2011-05-10T14:41:03.625+0200|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=83;_ThreadName=Thread-1;|--- end flummox ---|#]

Comment by tmpsa [ 10/May/11 ]

If it helps, I can mention that in our production system, when the combined "delete + insert" operation is made, the database has no entries in the join table (correspongning to foo_bar) but the webapp JPA system thinks that the relations still exist!
Hope this helps...

Comment by Chris Kasso [ 10/May/11 ]

Reopening the issue so that the RE can evaluate the issue with the additional info from the submitter.

Comment by Mitesh Meswani [ 11/May/11 ]

Hi Tmpsa,

I installed MySQL to run your test case. Unfortunately, I am still not able to reproduce the issue. Attached is server.log.0511 for the run that shows that the rows are being deleted and inserted.

Please note that I got an exception on Step B of your app because the relationships were already present in the database. I assume you would have also got the exception. What was your intention behind introducing step B?

Are you able to reproduce using the test case while running against a fresh database? If yes, I am truly lost about what may be the difference between our environments.

-Mitesh

Comment by Mitesh Meswani [ 11/May/11 ]

server.log depicting run and execution of correct SQLs

Comment by tmpsa [ 12/May/11 ]

Oops! I had a bug in my bug-reproducing program. My bad. How embarrasing! :-/ Mitesh, your observation is quite correct; there was an unnecessary duplication of the insert. Now fixed.

I dug into your server.log an noted that you run a later version of Glassfish than me.

  • I have vanilla 3.1 (build 43)
  • You have 3.1.1-SNAPSHOT (build mitesh-private)
    Hope that won't confound our efforts to nail this bug.

The bug is even more slippery than I thought. I was dismayed to see that my test program works just fine after a fresh 'create database', start GF, deploy and the prescribed steps. It was only after some fiddling around that I noticed that the bug suddenly occured again after I had re-deployed my test app.

That makes me think that there's something fishy going on with the GF JPA cache, but who knows...

So I have now fixed the silly error in my program, and written a longer test instruction (see read-me.txt). I really hope that you will be able to see the problem this time. See gfbug-15883-tickler-v2.zip !

Keeping my fingers crossed...

Comment by Mitesh Meswani [ 16/May/11 ]

Filled https://bugs.eclipse.org/bugs/show_bug.cgi?id=346022
Meanwhile, a possible workaround for you is to disable weaving

Comment by tmpsa [ 17/May/11 ]

Many thanks for finding the underlying bug!

Adding the following under <properties> in persistence.xml makes the bug disappear from both my test and production applications:

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

I have also seen recommendations to use

<property name="no.weaving" value="true"/>

but that does not help. What is the Right Way to disable weaving? I'm not an expert in that field. Please advise.

Comment by Mitesh Meswani [ 17/May/11 ]

>What is the Right Way to disable weaving?
Use <property name="eclipselink.weaving" value="false"/>

Comment by tmpsa [ 24/Aug/11 ]

Is it known in which version of Glassfish this bug will be fixed? It appears that the underlying bug was fixed in EclipseLink 2.3.0 "Indigo".

By the way, disabling weaving did not help, actually.

Comment by Mitesh Meswani [ 24/Aug/11 ]

Marking as Fixed in GlassFish 3.1.1 that ships with EclipseLink 2.3.0





[GLASSFISH-16960] asadmin cli timeout from ha execution on aix-2 Created: 05/Jul/11  Updated: 09/Aug/11  Resolved: 09/Aug/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 3.1.1

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

aix


Tags: 3_1-next_release-note-added, 3_1-next_release-notes

 Description   

glassfish-3.1.1-b10-aix.zip

The previous timout from ha long execution on b08 seems resolved in
http://java.net/jira/browse/GLASSFISH-16877
I observed hang twice with ha short execution on b10, and will provide test details next.



 Comments   
Comment by sherryshen [ 05/Jul/11 ]

With jvm setting to st-cluster as
org.shoal.cache.transmitter.max.batch.size=1,
I ran the SLSB suite with results in
http://agni-1.us.oracle.com/asqe-logs/export1/3.1.1/Results/build10/ha/test1/run11/summary/overall-summary.html
It passed on session, but failed on modified-session, modified-attribute.

After tests, the instances are gone unexpected, das seems hanging.
root@/export/home/sherrys # asadmin list-instances -l
No response from Domain Admin Server after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Command list-instances failed.
root@/export/home/sherrys #
root@/export/home/sherrys # ps -ef | grep java
pconsole 266410 282782 0 Jul 04 - 0:54 /usr/java5/bin/java -Xmaxe512m -Xmine20m -Xshareclasses -Dfile.encoding=UTF-8 -Xbootclasspath/a:/pconsole/lwi/runtime/core/rcp/eclipse/plugins/com.ibm.rcp.base_6.1.1.200707121104/rcpbootcp.jar:/pconsole/lwi/lib/ISCJaasModule.jar:/pconsole/lwi/lib/icl.jar:/pconsole/lwi/lib/jaas2zos.jar:/pconsole/lwi/lib/jaasmodule.jar:/pconsole/lwi/lib/lwinative.jar:/pconsole/lwi/lib/lwinl1.jar:/pconsole/lwi/lib/lwinl2.jar:/pconsole/lwi/lib/lwinl3.jar:/pconsole/lwi/lib/lwirolemap.jar:/pconsole/lwi/lib/passutils.jar -Xverify:none -cp eclipse/launch.jar:eclipse/startup.jar:rcp/eclipse/plugins/com.ibm.rcp.base_6.1.1.200707121104/launcher.jar com.ibm.lwi.LaunchLWI
root 323604 372920 0 13:55:58 pts/6 0:00 grep java
root 377080 1 0 16:28:18 pts/1 1188:20 /usr/java6_64/bin/java -cp
/export/home/ming/glassfish3/glassfish/modules/glassfish.jar
-XX:+UnlockDiagnosticVMOptions -XX:NewRatio=2
-XX:MaxPermSize=192m -Xmx512m
-javaagent:/export/home/ming/glassfish3/glassfish/lib/monitor/flashlight-agent.jar
-client
-Dcom.sun.aas.instanceRoot=/export/home/ming/glassfish3/glassfish/domains/st-domain
-Dfelix.fileinstall.bundles.startTransient=true
-Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command,org.apache.felix.fileinstall
-Djava.security.auth.login.config=/export/home/ming/glassfish3/glassfish/domains/st-domain/config/login.conf
-Dfelix.fileinstall.dir=/export/home/ming/glassfish3/glassfish/modules/autostart/ -Dosgi.shell.telnet.ip=127.0.0.1
-Dcom.ibm.xml.xlxp.support.dtd.compat.mode=false -Djavax.net.ssl.trustStore=/export/home/ming/glassfish3/glassfish/domains/st-domain/config/cacerts.jks
-Djava.security.policy=/export/home/ming/glassfish3/glassfish/domains/st-domain/config/server.policy -Djava.endorsed.dirs=/export/home/ming/glassfish3/glassfish/modules/endorsed:/export/home/ming/glassfish3/glassfish/lib/endorsed -Dfelix.fileinstall.bundles.new.start=true
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Dfelix.fileinstall.log.level=2
-Dfelix.fileinstall.poll=5000
-Dfelix.fileinstall.disableConfigSave=false
-Dosgi.shell.telnet.port=6666 -Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory
-DANTLR_USE_DIRECT_CLASS_LOADING=true
-Dosgi.shell.telnet.maxconn=1
-Djavax.net.ssl.keyStore=/export/home/ming/glassfish3/glassfish/domains/st-domain/config/keystore.jks
Dgosh.args=-nointeractive
-Dcom.sun.aas.installRoot=/export/home/ming/glassfish3/glassfish -Djava.awt.headless=true -Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
-Djava.ext.dirs=/usr/java6_64/lib/ext:/usr/java6_64/jre/lib/ext:/export/home/ming/glassfish3/glassfish/domains/st-domain/lib/ext -Djava.library.path=/export/home/ming/glassfish3/glassfish/lib:/usr/java6_64/jre/lib/ppc64/default:/usr/java6_64/jre/lib/ppc64:/usr/java6_64/jre/lib/ppc64/j9vm:/usr/java6_64/lib/ppc64:/usr/lib com.sun.enterprise.glassfish.bootstrap.ASMain -asadmin-classpath /export/home/ming/glassfish3/glassfish/modules/admin-cli.jar -verbose false -asadmin-classname com.sun.enterprise.admin.cli.AsadminMain -debug false -type DAS -asadmin-args
-host,,,localhost,,,-port,,,4848,,,
-secure=false,,,terse=false,,,-echo=false,,,
--interactive=true,,,start-domain,,,
-verbose=false,,,-debug=false,,,
--domaindir,,,/export/home/ming/glassfish3/glassfish/domains,,,st-domain
-domainname st-domain
-domaindir /export/home/ming/glassfish3/glassfish/domains/st-domain
-instancename server -read-stdin true -upgrade false
root 385034 315570 0 16:36:38 pts/2 0:29 java -jar bin/felix.jar
root@/export/home/sherrys #

Comment by sherryshen [ 05/Jul/11 ]

Tom took thread dump from the DAS process,
gave initial analysis, and wait for Justin's feedback.

Copy Tom's analysis.
I've scanned through this several times and I'm not seeing anything that
jumps out that would explain the hang.
There is no response when attempting to contact the process through port
4848 (the admin port). I tried with asadmin and the REST interface
(management and monitoring). A telnet to port 4848 accepts the
connection, but then there is no response when an URL is entered. So
this means that Grizzly is still accepting connections.

Port 8080 responds fine, port 8686 (to get the threaddump) responds.

I connected to the process fine with jconsole. There are 168 live
threads, with a peak of 223. The jconsole "detect deadlock" button
doesn't detect any deadlock. All 5 admin-thread-pool-4848 threads are in
the getTask method waiting for a task.

The memory profile looks reasonable (90MB non-heap, 99MB heap - growing
and being collected as expected).

I'm copying Justin on this as there might be something in the Grizzly
area that looks amiss.

Comment by Tom Mueller [ 06/Jul/11 ]

Here is some more analysis of this problem.

We left the process up overnight. When looking at the process the next day, both port 8080 and 8181 became non-responsive as well.

Looking at the thread stack traces, we found several threads with the same stack trace at the top. They start with:

Grizzly-kernel-thread(1) 53 RUNNABLE
sun.nio.ch.FileDispatcher.preClose0(Native Method)
sun.nio.ch.SocketDispatcher.preClose(SocketDispatcher.java:53)
sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel(SocketChannelImpl.java:705)
java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:212)
java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:108)
com.sun.grizzly.TCPSelectorHandler.closeChannel(TCPSelectorHandler.java:1304)

In the initial threaddump yesterday, there were 4 threads that were blocked in the preClose0 method. Today, when looking again, there are 7 threads.

The effected threads include:

  • Grizzly-kernel-thread(1) (2 of this kind)
  • GMS-McastMsgProcessor-Group-st-cluster-thread-6 (3 of this kind)
  • http-thread-pool-8181(1) (2 of this kind)

There is also a blocked thread that is waiting in a sun.nio.ch.SocketChannelImpl.socket call. The thread is blocked on one of the 7 threads blocked in preClose0.

A similar problem was reported in this Netty bug report:
http://www.jboss.org/netty/community#nabble-td3047474

This bug report says, "It seems like ServerSocketChannel.socket().accept().getChannel() should be used to get the exception raised."

Comment by Tom Mueller [ 06/Jul/11 ]

Interesting. I just did a kill -9 of the DAS on aixas10, and the process went into the following state according to ps:

  • 377080 - - - <exiting>

And the ports (4848, 8080, 8181, etc.) are still being listened on according to netstat.

This is apparently a problem that several people have had on AIX, see:

http://www.unix.com/aix/62248-command-release-port-aix.html
http://www.unix.com/aix/161812-how-kill-exiting-process-aix.html
http://www.tek-tips.com/viewthread.cfm?qid=831177&page=185
http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14450475

I suspect that the unresponsive ports (the hang) and the inability for the DAS to exit are actually related.

The last URL above references the following IBM bug report:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ72993

Clicking on the link on that page where it says to get the fix, it appears that aixas10.us.oracle.com does not have the fix.

That bug report says that the only way to terminate the application is to reboot.

Maybe the fix should be installed on this system, and maybe that fix will be a requirement for running GlassFish on AIX.

Comment by Alex Pineda [ 07/Jul/11 ]

Submitted lab tickets to the suggested IBM patch installed. The lab ticket details are:

  • Service Request: 21567871 - [ILM][SWA-SCA] Please install IBM patch on aixas10.us.oracle.com and sync time
  • Service Request: 21567881 - [ILM][SWA-SCA] Please install IBM patch on aixas7.us.oracle.com and sync time
  • Service Request: 21567887 - [ILM][SWA-SCA] Please install IBM patch on aixas12.us.oracle.com and sync time

the patch location is in the "Details" lab request. Have escalated the issues through the Lab tool, but no response as of yet.

Alex Pineda

Comment by scatari [ 08/Jul/11 ]

Potential release notes item if the patch resolves this issue. Marking appropriately.

Comment by Rebecca Parks [ 11/Jul/11 ]

It's not clear what needs to be stated in the Release Notes. Please clarify.

Comment by Tom Mueller [ 12/Jul/11 ]

If the AIX patch is found to resolve this issue, then the release notes should state that AIX
patch found here: https://www-304.ibm.com/support/docview.wss?uid=isg1fixinfo117990
is required to run GlassFish.

Comment by sherryshen [ 19/Jul/11 ]

On the first setup of aix machines for ha tests, we observed hanging for serveral times.
At the 6 th hanging during ha tests on v3.1.1 build 10, the ha test configurations are:
--aixas10, das and 2 instances, webserver, derby, DFT workspace for ha tests
--aixas7, 4 instances
--aixas12, 4 instances
Tom looked at das hanging on aixas10 and suggested IBM patch.
Jon used the following patch from IBM on aixas10
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ72993
which corrupted the system.

Then, we started tests on the second set of aix machines with slightly different configuration.
--bigapp-oblade-10 (Linux), webserver, derby, DFT workspace for ha tests
– aixas1, das and 3 instances
– aixas2, 3 instances
– aixas9, 4 instances.
We observed hanging twice on aixas1 during ha tests on 3.1.1 build 11.
Tom reviewed hanging and confirmed that it is the same issue on
on which he recommended the IBM patch.

Copying feedback from Tom:
On 7/19/2011 7:50 AM, Tom Mueller wrote:

Yes, this is the same issue. Here's how I checked.

1. Startup "jconsole" on your local host
2. Select "Remote Process" and enter "aixas1:8686" for the hostname/port and enter "admin" for the username. Click Connect.
3. Click on the Threads tab.
4. In the Filter box at the bottom, enter "kernel". This will show only the grizzly kernel threads.
5. Click on each thread in turn (there are about 6 of them) and look for a thread that is in the FileDispatcher.preClose0 method. If there is one, then the system is experiencing the problem that is solved by the IBM patch.

Tom

Comment by sherryshen [ 19/Jul/11 ]

Thank Tom for reviewing hanging problem and confirming the cause.
I started jconsole on bigapp-oblade-10 (Linux), connected aixas1 remotely,
and saw FileDispatcher.preClose0 according to Tom's instruction, e.g.

Name: Grizzly-kernel-thread(1)
State: RUNNABLE
Total blocked: 1 Total Waited: 12

Stack trace:
sun.nio.ch.FileDispatcher.preClose0(Native Method)
sun.nio.ch.SocketDispatcher.preClose(SocketDispatcher.java:53)
sun.nio.ch.SocketDispatcher.SocketChannelImpl.ImplCloseSelectableChannel(SocketChannelImpl.java:705)

  • locked java.lang.Object@23342334
Comment by Alex Pineda [ 21/Jul/11 ]

We need to document this issue in the Release Notes and the hope is that the following write-up provides the necessary information requested by our technical writer. The issue from QA standpoint can be viewed as:

During High Availability testing, the Domain Admin Server (DAS) freezes and requires a complete restart to resume system functionality. Developers identified an IBM patch that is available to resolve a similar problem. The patch is available can be download from : https://www-304.ibm.com/support/docview.wss?uid=isg1fixinfo117990. This issue can be viewed as a potential customer call generator and should be documented in the Release Notes

Comment by sherryshen [ 27/Jul/11 ]

The hanging issue was observed on ha execution on 3.1.1 build 12 and aix
after the suggested patch was installed on the aix machine with das.
One of the instance is hanging on das machine, and "kill -9 <pid> did not terminate the hang java process.
It looks as if an AIX reboot is going to be need to get rid of the hung java process.

Test configuration:
aixas10: das, 2 instances, derby, web server, dft workspace
aixas7: 4 instances
aixas12: 4 instances

Test details:
[1] check asadmin cli on aixas10 with das
1.1 Jon installed patch on aixas10 as Tom suggested on July 20, 2011
1.2 Ming set up the machines (aixas10, aixas7, aixas12) and started full executions on July 21, which end at July 22 night.
1.3 Sherry did http module execution from July 25 to July 26.
– Afternoon of July 25, the execution was started, and No hanging was observed with the first 1/3 of execution (89 tests in full session).
--Evening of July 25, the possible hanging was reported.
When the 2/3 of tests (89 tests in modified-session) started at the evening on July 25, timeout message was observed in
"asadmin list-instances -l", "asadmin get-health st-cluster" shows that 2 instances out of 10 instances were failed,
(instance101 on aixas10, instance103 on aixas7). Tests were still in progress.
--Morning of July 26, "asadmin get-health st-cluster" shows that 1 instance out of 10 instances was failed (instance101 on aixas10).
Tests were in progress of the last 1/3 of tests (89 tests in modified attributes), which were completed at
that evening (Tue Jul 26 17:17:16 PDT 2011).
--Morning, July, Tom looked aix machines, and identified that instance101 were hanging.
From Tom:
"However, it doesn't appear to be the same symptom as other hangs. Port 28080 is non-responsive.
Port 28686 (the JMX port) is non-responsive. When we had the hang before, these ports were responsive.
Because the JMX port is unresponsive, the threaddump program cannot get the threaddump from this process."
--Afternoon, July 26, Tom tried running kill -3 against the hung process, but it didn't generate the dump file.
So the process must be hung in such a way that it isn't responsive to the QUIT signal.
--Evening, July 28, Jon installed dbx on aixas10 according to Tom's suggestion.
--Morning of July 27, Tom checked machines with dbx, and gave his best guess that this is a IBM JVM or AIX problem
related to memory allocation. Tom also tried a kill -9 on the hung java process, and it will not terminate either.
It looks as if an AIX reboot is going to be need to get rid of the hung java process.
--Morning, July 27, Sherry checked machines after Tom provided his feedback.
instance101 is still hanging.
bash-3.2# date
Wed Jul 27 10:02:54 PDT 2011
bash-3.2# asadmin get-health st-cluster
instance101 failed since Mon Jul 25 17:38:44 PDT 2011
instance102 started since Tue Jul 26 17:14:02 PDT 2011
instance103 started since Tue Jul 26 17:14:19 PDT 2011
instance104 started since Wed Jul 27 06:54:17 PDT 2011
instance105 started since Tue Jul 26 17:14:03 PDT 2011
instance106 started since Tue Jul 26 17:14:19 PDT 2011
instance107 failed since Wed Jul 27 06:34:26 PDT 2011
instance108 started since Tue Jul 26 17:14:09 PDT 2011
instance109 started since Tue Jul 26 17:14:17 PDT 2011
instance110 started since Tue Jul 26 17:14:20 PDT 2011
Command get-health executed successfully.
bash-3.2# asadmin version
Version = GlassFish Server Open Source Edition 3.1.1 (build 12)
Command version executed successfully.
bash-3.2# asadmin list-instances instance102
instance102 running
Command list-instances executed successfully.
bash-3.2# asadmin list-instances instance107
instance107 not running
Command list-instances executed successfully.
bash-3.2# asadmin list-instances instance101
No response from Domain Admin Server after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Command list-instances failed.
bash-3.2#

[2] ha tests on v3.1.1 build 10 and aix
When one instance is hanging during the middle of tests, the tests are completed with more failures
2.1)The first full ha execution after aixas10 is patched.
http://agni-1.us.oracle.com/net/asqe-logs.us.oracle.com/export1/3.1.1/Results/build12/ha/aix/results/summary/overall-summary.html
2.1.1) http (full session) 89 tests, 89 pass, 0 fail
2.1.2) http-modified-session, 89 tests, 89 pass, 0 fail
2.1.3) http-modified-attribute, 89 tests, 86 pass, 3 fail
2.2) The http rerun on previous setup
http://agni-1.us.oracle.com/net/asqe-logs.us.oracle.com/export1/3.1.1/Results/build12/ha/aix2/summary/overall-summary.html
2.2.1) http (full session) 89 tests, 83 pass, 6 fail
2.2.2) http-modified-session, 89 tests, 43 pass, 46 fail (instance101 hang in late part of the execution)
2.2.3) http-modified-attribute, 89 tests, 2 pass, 74 fail, 13 skip (instance101 hang in entire execution)

Comment by sherryshen [ 27/Jul/11 ]

I raised an asadmin cli question from the tests in
http://java.net/jira/browse/GLASSFISH-16960
When one instance is hanging and another instance is killed or stopped in
"asadmin list-instances" gives timeout message,
"asadmin get-health st-cluster" gives 2 instances in failed status,
any way to report hanging status to help user to understand the problem?

Thank Tom for filing the bug,
http://java.net/jira/browse/GLASSFISH-17116
It fix will help user to understand the status of instances.

Comment by sherryshen [ 28/Jul/11 ]

For more failure with a hanging instance in [2],
one reason is deploy failure in
http://java.net/jira/browse/GLASSFISH-17128

Comment by sherryshen [ 08/Aug/11 ]

glassfish 3.1.1 build 12 on aix

Comment by sherryshen [ 08/Aug/11 ]

According to Tom's analysis and suggestion, I filed another bug
http://java.net/jira/browse/GLASSFISH-17160
to track the last hanging after the IBM patch for "application hangs
when closing socket file descriptors" was applied.

Comment by Justin Lee [ 09/Aug/11 ]

It doesn't appear that there's anything (yet?) to do on the grizzly side.

Comment by Tom Mueller [ 09/Aug/11 ]

The fix for this issue is to apply the indicated patch from IBM to the AIX system.
Marking this as resolved.





[GLASSFISH-17064] (UB) Document update center client limitations on AIX platform Created: 19/Jul/11  Updated: 21/Jul/11  Resolved: 21/Jul/11

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