[GLASSFISH-16476] admin CLI logging changes causes problems in admin dev tests Created: 27/Apr/11  Updated: 27/Apr/11  Resolved: 27/Apr/11

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

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

Tags: 3_1_1-approved

 Description   

Fixes to the admin CLI main program's logging caused the output and error streams to close incorrectly, in turn causing problems with some of the dev tests.

  • Why fix this issue in 3.1.1?
    Causes problems in admin devtests which could mask other regressions.
  • Which is the targeted build of 3.1.1 for this fix?
    3.1.1-b03
  • Do regression tests exist for this issue?
    yes
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    admin CLI devtests will cover this


 Comments   
Comment by scatari [ 27/Apr/11 ]

Approved.

Comment by Tim Quinn [ 27/Apr/11 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 46473
Author: tjquinn
Date: 2011-04-27 15:47:32 UTC
Link:

Log Message:
------------
Fix for 16476

Part of an earlier fix to correct a deficiency in CLI logging caused problems in some dev tests which sampled the error output stream. This fix (checked in earlier to the trunk) cures that problem.

Approved: Sathyan
Tests: QL, selected admin CLI devtests which showed the problem

Revisions:
----------
46473

Modified Paths:
---------------
branches/3.1.1/admin/cli/src/main/java/com/sun/enterprise/admin/cli/AsadminMain.java





[GLASSFISH-16468] Wrong version info in bundle "ogs-3.1.1-web-b02-unix-ml.sh" Created: 27/Apr/11  Updated: 16/May/11  Resolved: 29/Apr/11

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

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

Server OS: RHEL 5
Bundle: ogs-3.1.1-web-b02-unix-ml.sh
Locale: fr, EN


Attachments: JPEG File version_gf3.2_build2.jpg    

 Description   

The version info was displayed as Oracle GlassFish Server 3.2 (build 2)

To reproduce:
1. Install the bundle named "ogs-3.1.1-web-b02-unix-ml.sh".
2. Go to Admin Console GUI, and click on About button in the top of page.
OR, execute command "./asadmin version" under the GF_Install_Directory/glassfish/bin/ folder, the output will be Oralce GlassFish Server 3.2 (build 2).

Attached screen shot for your reference.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 27/Apr/11 ]

FWIW, this should be fixed in 3.1.1 b03 since version parameters have been adjusted in 04/25 commit...

Comment by sunny-gui [ 29/Apr/11 ]

Verified and fixed in gf 3.1.1 b03. Here are the verified info details.

Bundle: ogs-3.1.1-web-b03-unix-ml.sh
OS: OEL 5.5 x86
Locale: fr, zh_CN

Comment by Snjezana Sevo-Zenzerovic [ 29/Apr/11 ]

Closing based on submitters comment.





[GLASSFISH-16444] appclient failure of smoke tests on aix Created: 24/Apr/11  Updated: 12/May/11  Resolved: 27/Apr/11

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

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

AIX


Attachments: File go.sh     Text File output.txt     Zip Archive testLongCommand.zip    
Tags: 3_1_1-approved

 Description   

3.1.1 b02 on AIX

appserver-sqe/pe/ejb/mdb/basic shows the failure

runclient-common:
[echo] Executing appclient at /export/hudson/workspace/alex-aix-smoke/appserver-sqe/pe/ejb/mdb/basic
[exec] Result: 1
[echo] Apr 22, 2011 3:12:11 PM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[echo] 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.
[echo] org.glassfish.appclient.client.acc.UserError: Client Container xml:
/export/hudson/workspace/alex-aix-smoke/gl not found or unable to read.
[echo] You may want to use the -xml option to locate your configuration xml.
[echo] Usage :
[echo] appclient [<classfile> | -client<appjar> ]
[echo] [-mainclass<appClass-name>|-name<display-name>]
[echo] [-xml<xml>]
[echo] [-textauth] [-user<username>] [-password<password>|-passwordfile<password-file>]
[echo] [-targetserver host[:port][,host[:port]...]
[echo] [app-args]
[echo] or :
[echo] appclient [<valid JVM options and valid ACC options> ]
[echo] [<appClass-name> | -jar<appjar> ]
[echo] [app args]



 Comments   
Comment by scatari [ 24/Apr/11 ]

Does this path export/hudson/workspace/alex-aix-smoke/gl exist? This most likely is the test setup or ordering issue. Approving for 3.1.1 as this is the blocker for SQE Smoke tests.

Comment by Tim Quinn [ 25/Apr/11 ]

(from an e-mail I sent over the weekend, similar to Sathyan's thought)

Possible reasons for the error message:

1. The test specifies -xml pathToFile and that path does not exist or cannot be read.
2. The test specifies -configxml pathToFile and that path does not exist or cannot be read.
3. The test specifies neither -xml nor -configxml and the default, which is $

{domainDir}

/config/sun-acc.xml does not exist or cannot be read.

The error message says it cannot use

/export/hudson/workspace/alex-aix-smoke/gl

as the XML file so I suspect that either case 1 or 2 applies here.

Comment by Tim Quinn [ 25/Apr/11 ]

Sherry sent me separately part of the test output. Below is the relevant part. Note that the command as echoed by ant specifies

-xml /export/hudson/workspace/alex-aix-smoke/glassfish3/glassfish/domains/domain1/config/sun-acc.xml

but the error message from the ACC says it cannot locate

/export/hudson/workspace/alex-aix-smoke/gl

which is the first 42 characters of the command-line argument value.

It's not yet clear to me where the truncation is occurring. Investigating.

runclient-common:
[echo] Executing appclient at /export/hudson/workspace/alex-aix-smoke/appserver-sqe/pe/ejb/mdb/basic
[exec] Current OS is AIX
[exec] Output redirected to property: runclientCommonOutput
[exec] Setting environment variable: APPCPATH=
[exec] Setting environment variable: VMARGS=
[exec] Executing '/export/hudson/workspace/alex-aix-smoke/glassfish3/glassfish/bin/appclient' with arguments:
[exec] '-client'
[exec] '/export/hudson/workspace/alex-aix-smoke/appserver-sqe/build/pe/ppc_aixas13_AIX/ejb-mdb/archive/ejb-mdb-basicAppClient.jar'
[exec] '-name'
[exec] 'ejb-mdb-basicClient'
[exec] '-textauth'
[exec] '-user'
[exec] 'j2ee'
[exec] '-password'
[exec] 'j2ee'
[exec] '-xml'
[exec] '/export/hudson/workspace/alex-aix-smoke/glassfish3/glassfish/domains/domain1/config/sun-acc.xml'
[exec] 'basicJMS2EJB'
[exec]
[exec] The ' characters around the executable and arguments are
[exec] not part of the command.
[echo] Apr 24, 2011 11:13:03 AM org.glassfish.appclient.client.acc.Appclien
tCommandArguments warnAboutPasswordUsage
[echo] 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.
[echo] org.glassfish.appclient.client.acc.UserError: Client Container xml:
/export/hudson/workspace/alex-aix-smoke/gl not found or unable to read.
[echo] You may want to use the -xml option to locate your configuration xml

Comment by Tim Quinn [ 25/Apr/11 ]

The appclient script works by running Java twice. The first run takes the command-line arguments and other information and actually generates a second java command. This second java command is the one that actually launches the app client container.

The problem seems to be that there is a character limit somewhere. I purposefully removed one character from the username value passed on the command line, and the ACC received one additional character of the truncated path to the sun-acc.xml file.

This and other information is passed to the ACC as a Java agent argument string. I suppose there could be a limit on the length of the string accepted as a Java agent argument, although that seems unlikely.

Also, the first run of Java writes the generated command to System.out which is processed by the "eval" shell command to invoke java the second time (this time launching the ACC). This returned command can be lengthy, so there could be some issue with the length of the command that is returned to the shell script and then executed in that script.

Comment by sherryshen [ 25/Apr/11 ]

Thanks Tim for the update of the issue about length.
Here is another smoke test run on the same machine from Bhakti.
Sunce her job has a longer name, the string in error message is shorter.

org.glassfish.appclient.client.acc.UserError: Client Container xml:
/export/h not found or unable to read.

http://sqe-hudson.us.oracle.com:8080/hudson/job/glassfish-3.1.1-aix-smoke/7/console

runclient-common:
[echo] Executing appclient at /export/hudson/workspace/glassfish-3.1.1-aix-smoke/appserver-sqe/pe/ejb/mdb/basic
[exec] Result: 1
[echo] Apr 21, 2011 11:16:26 AM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[echo] 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.
[echo] org.glassfish.appclient.client.acc.UserError: Client Container xml: /export/h not found or unable to read.

Comment by scatari [ 25/Apr/11 ]

This could be a limitation in ant if you are using ANT. I have seen these errors when executing "cvs" command with a long command line from ANT.

Comment by Tim Quinn [ 26/Apr/11 ]

After some experimentation on an AIX system, here is what I found: there is definitely some length limitation being imposed.

This does not seem to involve ant. At the command prompt I can launch a simple app client successfully using the appclient script. Then I artificially lengthened the java command which the appclient script generates by specifying -xml pathToFile multiple times. (The ACC uses the last value specified.) Using this technique I could cause the launch to fail, as in the test script, because the file path to the sun-acc.xml file was truncated somewhere along the way. (This was all outside ant.)

So the limit seems to be coming from either the shell or from java command line parsing. Further it's not yet clear whether the limit is on the overall command length or on the size of a single token on the command line.

I am still investigating.

Comment by scatari [ 26/Apr/11 ]

Some more data that might help.

Interestingly if both "-configxml" and "-xml" argument values are long, then only you get this error. If one of them is really big and the other one comparitively smaller then no errors.

,arg=-configxml,arg="/export/hudson/workspace/glassfish-3.1.1-aix-smoke/glassfish3/glassfish/domains/domain1/config/sun-acc.xml"
+
,arg=-xml,arg="/tmp/sun-acc.xml"

works where as

,arg=-configxml,arg="/export/hudson/workspace/glassfish-3.1.1-aix-smoke/glassfish3/glassfish/domains/domain1/config/sun-acc.xml"
+
,arg=-xml,arg="/export/hudson/workspace/glassfish-3.1.1-aix-smoke/glassfish3/glassfish/domains/domain1/config/sun-acc.xml"
Doesn't work.

I don't think this is a limitation in # of characters also as the output script that I generated by calling appclient has < 2000 characters. Not sure why there is a repetition in command-line arguments.

This is the generated command line.(Ignore the line feeds)

"/export/hudson/tools/java6/bin/java" -Dcom.sun.aas.installRoot="/export/hudson/workspace/gl
assfish-3.1.1-aix-smoke/glassfish3/glassfish/bin/.." -Djava.security.policy="/export/hudson/
workspace/glassfish-3.1.1-aix-smoke/glassfish3/glassfish/bin/../lib/appclient/client.policy"
-Djava.system.class.loader=org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader -Dj
ava.security.auth.login.config="/export/hudson/workspace/glassfish-3.1.1-aix-smoke/glassfish
3/glassfish/bin/../lib/appclient/appclientlogin.conf" -javaagent:"/export/hudson/workspace/
glassfish-3.1.1-aix-smoke/glassfish3/glassfish/bin/../lib/gf-client.jar"=mode=acscript,arg=-
configxml,arg="/export/hudson/workspace/glassfish-3.1.1-aix-smoke/glassfish3/glassfish/domai
ns/domain1/config/sun-acc.xml",client=jar="/export/hudson/workspace/glassfish-3.1.1-aix-smok
e/appserver-sqe/build/pe/ppc_aixas13_AIX/ejb-mdb/archive/ejb-mdb-basicAppClient.jar",arg=-na
me,arg="ejb-mdb-basicClient",arg=-textauth,arg=-user,arg="j2ee",arg=-password,arg="j2ee",arg
=-xml,arg="/tmp/sun-acc.xml" -Djava.ext.dirs="/export/hudson/workspace/glassfish-3.1.1-aix-s
moke/glassfish3/glassfish/bin/../lib/ext":"/export/hudson/tools/java6/jre/lib/ext" -Djava.en
dorsed.dirs="/export/hudson/workspace/glassfish-3.1.1-aix-smoke/glassfish3/glassfish/bin/../
lib/endorsed":"/export/hudson/workspace/glassfish-3.1.1-aix-smoke/glassfish3/glassfish/bin/.
./modules/endorsed":"/export/hudson/tools/java6/jre/lib/endorsed" -jar "/export/hudson/work
space/glassfish-3.1.1-aix-smoke/appserver-sqe/build/pe/ppc_aixas13_AIX/ejb-mdb/archive/ejb-m
db-basicAppClient.jar" "basicJMS2EJB"

Comment by Tim Quinn [ 26/Apr/11 ]

My suspicion - not yet confirmed - has been that there might be a limit on the size of the options string (it appears after the = sign in -javaagent:pathToAgent= ) which is passed to the Java agent.

The command string generated by the first invocation of java and returned to the appclient script is correct; it is very long and includes the entire correct Java agent options string. But by the time the agent is invoked it receives only part of the string.

The total length of the token starting with -javaagent seems to be very close to (perhaps exactly) 512 characters, which is a familiar number. More news soon.

Comment by Tim Quinn [ 27/Apr/11 ]

It indeed looks like the -javaagent options value - or perhaps the entire -javaagent token - is length-limited.

I have attached a very simple test program (tstLongCommand.zip - a NetBeans project source and JAR files) which contains a Java agent. This program generates a long string (length controlled by a command line argument). Then, like the first Java execution in the appclient script, this test program emits a second java command which specifies a Java agent with a long options string and also specifies a property setting using the same long value.

The second run of the program simply displays the length and content of the agent options string and the same for the property value that's assigned on the generated command line.

I have also attached a simple shell script (go.sh) which drives the program.

The attached output file (output.txt) contains the output from running to generate a use a 600-character value. The results show that the system property value flows through to the program correctly, but the options value is truncated at 451 characters.

This is the option (excluding the long generated string) from the sample output; the full filespec to the JAR is part of the option so running the sample app in different environments will probably show different truncation points:

-javaagent:/export/hudson/workspace/tim/TestLongCommand.jar=(long string)

Interestingly, the token up to and including the = is 69 characters, and 69 + 451 is 511, certainly an interesting number.

Because the property is handled correctly but the -javaagent options value is not, that strongly suggests that this is not a shell token parsing issue but an issue with the AIX Java implementation and its handling of the options string.

Comment by Tim Quinn [ 27/Apr/11 ]

Fix checked in for 3.1.1 (rev 46488) and the trunk (rev 46490).

epository: svn
Revision: 46488
Author: tjquinn
Date: 2011-04-27 21:49:20 UTC
Link:

Log Message:
------------
"Fix" for 16444

This is actually a workaround for an apparent limitation in IBM's Java on AIX. The options string

-javaagent:pathToAgent=options

seems to be truncated if the entire -javaagent token exceeds 512 characters (give or take a couple of characters).

Some of the ACC work is done by a Java agent so it can get control before the user's client (and so the gf-client.jar can be on the classpath without requiring it to be explicitly specified in -classpath). The options value passed to the agent can be quite large because it includes most of the command-line arguments and options the user specifies when invoking the appclient script - and then some. The large value combined with a potentially long path to the the agent JAR caused the options string which Java passes to the agent to be truncated.

This fix causes CLIBootstrap to write the options to a file, then specify the file in the options string. Then the app client agent reads the actual options from the temp file before deleting it (unless a private, unpublished property is set to keep the options file for diagnosing any problems that might occur).

Approved: Sathyan
Tests: QL, deployment devtests, spot tests on AIX

Revisions:
----------
46488

Comment by sherryshen [ 02/May/11 ]

verified the fix on 3.1.1 b03.

Comment by Tim Quinn [ 12/May/11 ]

Adjust fixed-in date.





[GLASSFISH-16365] Admin QL failure on AIX Created: 15/Apr/11  Updated: 06/Jun/11  Resolved: 23/Apr/11

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: None
Fix Version/s: 3.1.1_b03

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

Tags: 3_1_1-approved

 Description   

We see the following error on AIX QL.
The bean validator osgi error is taken care of by copying bean-validator.jar to gf/lib. I tried this morning and do not see any bean validator error in server log
Please can you take a look in this issue

[echo] =============Starting TestNG test at ..//classes/test from testng.xml ============
[testng] [Parser] Running:
[testng] /export/bhakti/tempGF/3.1.1/tests/quicklook/admin/testng.xml
[testng]
[testng] PASSED: createJoe
[testng] PASSED: createPool
[testng] PASSED: ensureCreatedPoolExists
[testng] PASSED: ensureCreatedJoeExists
[testng] PASSED: deleteJoe
[testng] PASSED: deletedJoeDoesNotExist
[testng] PASSED: deletePool
[testng] PASSED: deletedPoolDoesNotExist
[testng] PASSED: createListener
[testng] PASSED: ensureCreatedListenerExists
[testng] PASSED: deleteListener
[testng] PASSED: ensureDeletedListenerDoesNotExist
[testng] PASSED: createListenerWithOldParam
[testng] PASSED: deleteListener2
[testng] FAILED: pingPool
[testng] java.lang.RuntimeException: null
[testng] at test.admin.util.GeneralUtils.handleManifestFailure(GeneralUtils.java:141)
[testng] at test.admin.JdbcConnectionPoolTests.pingPool(JdbcConnectionPoolTests.java:85)
[testng] ... Removed 22 stack frames
[testng]
[testng] ===============================================
[testng] asadmin_tests
[testng] Tests run: 15, Failures: 1, Skips: 0
[testng] ===============================================
[testng]
[testng]
[testng] ===============================================
[testng] QuickLookTests
[testng] Total tests run: 15, Failures: 1, Skips: 0
[testng] ===============================================
[testng]



 Comments   
Comment by Jagadish [ 15/Apr/11 ]

Transferring the issue to "JCA" as the root cause is Default Bean validator is not available for use in order the process bean-validation-annotations defined in resource-adapter. As a result JDBC-RA is not bootstrapped and ping-connection-pool QL failed.

This issue should be automatically resolved once
http://java.net/jira/browse/GLASSFISH-10590
is fixed.

Comment by Bhakti Mehta [ 20/Apr/11 ]

This failure is still showing up even after Sahoo fixed 16364
There is no error in server.log
Requesting Jagadish to look into it

You can use the aixas14 machine and there is gf installed /export/bhakti/glassfish-ap20 which has b55 bits from the hudson job http://gf-hudson.us.oracle.com/hudson/job/gf-3.1.1-aix-build/55
runtest-impl-xml:
[echo] =============Starting TestNG test at ..//classes/test from testng.xml ============
[testng] [Parser] Running:
[testng] /export/bhakti/tempGF/3.1.1/tests/quicklook/admin/testng.xml
[testng]
[testng] PASSED: createJoe
[testng] PASSED: createPool
[testng] PASSED: ensureCreatedPoolExists
[testng] PASSED: ensureCreatedJoeExists
[testng] PASSED: deleteJoe
[testng] PASSED: deletedJoeDoesNotExist
[testng] PASSED: createListener
[testng] PASSED: deletePool
[testng] PASSED: deletedPoolDoesNotExist
[testng] PASSED: ensureCreatedListenerExists
[testng] PASSED: deleteListener
[testng] PASSED: ensureDeletedListenerDoesNotExist
[testng] PASSED: createListenerWithOldParam
[testng] PASSED: deleteListener2
[testng] FAILED: pingPool
[testng] java.lang.RuntimeException: null
[testng] at test.admin.util.GeneralUtils.handleManifestFailure(GeneralUtils.java:141)
[testng] at test.admin.JdbcConnectionPoolTests.pingPool(JdbcConnectionPoolTests.java:85)
[testng] ... Removed 22 stack frames
[testng]
[testng] ===============================================
[testng] asadmin_tests
[testng] Tests run: 15, Failures: 1, Skips: 0
[testng] ===============================================
[testng]
[testng]
[testng] ===============================================
[testng] QuickLookTests
[testng] Total tests run: 15, Failures: 1, Skips: 0
[testng] ===============================================
[testng]

Comment by Jagadish [ 23/Apr/11 ]

Original issue w.r.t default-bean-validator availability is fixed.

Another issue is due to testng's behavior or JDK's behavior that causes the
reversal in order of test execution.

The tests are supposed to run in the following fashion :

create-pool
ensure-that-pool-exists
ping-pool
delete-pool
ensure-that-pool-does-not-exist

But, in AIX it seems to run in the following order :

create-pool
ensure-that-pool-exists
delete-pool
ensure-that-pool-does-not-exist
ping-pool

as a result, ping-pool test was failing.

Changed the test-case such that ping-pool is always executed before delete-pool.

Fix is made available in Trunk as well 3.1.1 branch.

FIX INFORMATION :
svn log -v -r 46346 [Trunk]
svn log -v -r 46295 [3.1.1 branch]

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





[GLASSFISH-16363] automatic self recovery failure with xa tx on 2 DBs Created: 15/Apr/11  Updated: 20/Apr/11  Resolved: 18/Apr/11

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

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

RHL5 and JDK1.6.0_24


Tags: 3_1_1-approved

 Description   

automatic self recovery failure with xa tx on 2 DBS
glassfish-3.1-b43.zip

I observed this intermittent failure of automatic self recovery
a few times in full core run, tx module run and cliweb2 suite run.
I will provide test details next for
tx-cliweb2-t4-killGFInstanceAutomaticSelfRecovery



 Comments   
Comment by sherryshen [ 15/Apr/11 ]

The test description is about TX_03R in test spec
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/docs/sqe/txn/GF31TXRecoveryTestSpec.html
1) with automatic-recovery=true
2) without delegated-recovery setting
3) do jdbc operations on a AS instance, e.g. i2, on DB_A, DB_B, and wait at prepared in 2PC;
4) kill that AS instance, i2;
5) restart the instance, i2, where automatic-recovery happens upon restart;
6) wait for 45 seconds, and then check recovery results with a running instance, e.g. i1.

The logs are saved at
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build43/tx/setupCluster.log
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build43/tx/test.output
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build43/tx/server.log.in1
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build43/tx/server.log.in2
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build43/tx/server.log.in3

The test env has a cluster of 3 instances on 1 machine as shown in setupCluster.log

list-instances-common:
[exec] asadmin --host localhost --port 4848 --user admin
--passwordfile /export/hudson/workspace/sherry-rhl-lc-dbg/appserver-sqe/build-config/adminpasswordfile.txt
--interactive=false --echo=true --terse=false list-instances --long=true
--timeoutmsec 2000 --standaloneonly=false --nostatus=false
[exec] NAME HOST PORT PID CLUSTER STATE
[exec] clustered_instance_1 localhost 34848 5384 sqe-cluster running
[exec] clustered_instance_2 localhost 44848 5504 sqe-cluster running
[exec] clustered_instance_3 localhost 54848 5625 sqe-cluster running
[exec] Command list-instances executed successfully.

The client out in test.output show the failure at step 6.

verify-data:
[echo] Executing test on port 38080
[java] WS HOME appserver-sqe
[java] main: testCase=verify_two
[java] invoking webclient servlet at http://localhost:38080/cliweb2/VerifyServlet?two
[java] Processing line: RESULTS:Exception
[java] FAILURE
[java] did not get expectedResult=RESULTS:6
[java] Generating report at /export/hudson/workspace/sherry-rhl-lc-dbg/appserver-sqe/test_results.xml

[java] -----------------------------------------
[java] - tx-cliweb2-t4-killGFInstanceAutomaticSelfRecovery: FAIL -

At step 3, FailPoint was shown at correct spot on i2, i.e. server.log.in2
[#|2011-04-12T15:06:27.472-0700|WARNING|glassfish3.1|javax.enterprise.system.core.transaction.com.sun.jts.utils.RecoveryHooks|_ThreadID=139;_ThreadName=Thread-1;|JTS5057: FailPoint : [2]|#]

At step 5, I saw instance restarted with app loaded, but did not see message about automatic-recovery in server.log.in2

[#|2011-04-12T15:06:58.709-0700|INFO|glassfish3.1|ShoalLogger|_ThreadID=10;_ThreadName=Thread-1;|GMS1099: GMS:Reporting Joined and Ready state to group: sqe-cluster|#]

[#|2011-04-12T15:06:58.718-0700|INFO|glassfish3.1|ShoalLogger|_ThreadID=12;_ThreadName=Thread-1;|GMS1092: GMS View Change Received for group: sqe-cluster : Members in view for JOINED_AND_READY_EVENT(before change analysis) are :
1: MemberId: clustered_instance_1, MemberType: CORE, Address: 10.133.184.142:9198:228.9.184.55:31480:sqe-cluster:clustered_instance_1
2: MemberId: clustered_instance_2, MemberType: CORE, Address: 10.133.184.142:9133:228.9.184.55:31480:sqe-cluster:clustered_instance_2
3: MemberId: clustered_instance_3, MemberType: CORE, Address: 10.133.184.142:9191:228.9.184.55:31480:sqe-cluster:clustered_instance_3
4: MemberId: server, MemberType: SPECTATOR, Address: 10.133.184.142:9179:228.9.184.55:31480:sqe-cluster:server

#]

Then, "Recovery of Inbound Transactions started." is shown in server.log.in2, but not in1 and in3.

At step 6, tests failed to access i1 to verify the results with error in server.log.in2

"TS5064: Unexpected exception occurred while delisting the resource"

[#|2011-04-12T15:07:44.965-0700|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=142;_ThreadName=Thread-1;|VerifyServlet,type=two|#]

[#|2011-04-12T15:07:45.155-0700|INFO|glassfish3.1|org.hibernate.validator.engine.resolver.DefaultTraversableResolver|_ThreadID=22;_ThreadName=Thread-1;|Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.|#]

[#|2011-04-12T15:07:45.595-0700|INFO|glassfish3.1|javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions|_ThreadID=142;_ThreadName=Thread-1;|JTS5014: Recoverable JTS instance, serverId = [100]|#]

[#|2011-04-12T15:07:45.629-0700|INFO|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.inbound|_ThreadID=154;_ThreadName=Thread-1;|Recovery of Inbound Transactions started.|#]

[#|2011-04-12T15:08:45.868-0700|WARNING|glassfish3.1|javax.enterprise.system.core.transaction.com.sun.jts.jta|_ThreadID=142;_ThreadName=Thread-1;|JTS5064: Unexpected exception occurred while delisting the resource
org.apache.derby.client.am.XaException: XAER_RMFAIL : No current connection.
at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown Source)
at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown Source)
at org.apache.derby.client.net.NetXAResource.connectionClosedFailure(Unknown Source)
at org.apache.derby.client.net.NetXAResource.end(Unknown Source)
at com.sun.gjc.spi.XAResourceImpl.end(XAResourceImpl.java:102)
at com.sun.jts.jta.TransactionState.beforeCompletion(TransactionState.java:160)
at com.sun.jts.jta.SynchronizationImpl.before_completion(SynchronizationImpl.java:135)
at com.sun.jts.CosTransactions.RegisteredSyncs.distributeBefore(RegisteredSyncs.java:158)
at com.sun.jts.CosTransactions.TopCoordinator.beforeCompletion(TopCoordinator.java:2561)
at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:279)
at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:250)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:319)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:184)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:873)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:5115)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4880)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2039)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy125.verifyxa(Unknown Source)
at txn.recovery.cliweb2._EJB31_GeneratedMyBeanIntf__Bean_.verifyxa(Unknown Source)
at txn.recovery.cliweb2.VerifyServlet.doGet(VerifyServlet.java:47)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java: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: org.apache.derby.client.am.SqlException: No current connection.
... 49 more

#]

To reproduce the failure:
do "ant ee all_test4" in
appserver-sqe/pe/transaction/recovery/cliweb2
with sqe cluster env setup in
http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=V31CoreInstruction

The reference can be also found in this hudson job.
http://sqe-hudson.us.oracle.com:8080/hudson/job/sherry-rhl-lc-dbg/
cvs co appserver-sqe/bootstrap.xml
cd $SPS_HOME
ant -f bootstrap.xml co-transaction > /dev/null
ant setup-cluster-profile > $WORKSPACE/setupCluster.log
ant startDerby > $WORKSPACE/startDerby.log
ant startTxDerby
cd $SPS_HOME/pe/transaction/recovery/cliweb2
ant ee all_test4 | tee test.output

Comment by marina vatkina [ 15/Apr/11 ]

This bug should be fixed in 3.1.1 (or 3.2) with rev 45615 (part of the fix for GLASSFISH-15802).

I'm surprised that it works for you in most cases in 3.1. Do you have another app with either a remote EJB or a timer (or a singleton doing something on startup) deployed at the same time? If yes, on the instance restart it would start an xa transaction early enough and trigger the recovery. If not, it's a miracle

Please check if with the latest promoted build and see if the problem goes away.

Comment by sherryshen [ 15/Apr/11 ]

The tests also failed on v3.2 b02, #2 in
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_v31/job/sherry-rhl-dbg-lc/
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build43/tx/server.log.in1.v32b2
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build43/tx/server.log.in2.v32b2
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build43/tx/server.log.in3.v32b2

Comment by sherryshen [ 17/Apr/11 ]

The test spec has a note that this test case initially passed on v3.1 b29.
I reran tests today, and the tests still passed on v3.1 b29.
See <http://sqe-hudson.us.oracle.com:8080/hudson/job/sherry-rhl-dbg-lc/3/>
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build43/tx/setupCluster.log.v31b29
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build43/tx/test.output.v31b29
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build43/tx/server.log.in1.v31b29
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build43/tx/server.log.in2.v31b29
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build43/tx/server.log.in3.v31b29

Comment by marina vatkina [ 18/Apr/11 ]

Yes. I can reproduce the problem with a devtest. I'm still wondering what's the setup difference when it passes...

Comment by marina vatkina [ 18/Apr/11 ]

Fixed with rev 46217. The actual fix for this issue is this change in JavaEETransactionManagerJTSDelegate:

  • TransactionServiceProperties.getJTSProperties(habitat, false);
    + Properties props = TransactionServiceProperties.getJTSProperties(habitat, false);
    + DefaultTransactionService.setServerName(props);
Comment by marina vatkina [ 18/Apr/11 ]
  • Why fix this issue in 3.1.1?

Automatic transaction recovery on server restart is not working

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

The next.

  • Do regression tests exist for this issue?

Yes. A devtest was added. SQE test existed since 3.1

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

Transaction tests, including recovery tests

Comment by scatari [ 18/Apr/11 ]

Approved. Please look here http://wikis.sun.com/display/GlassFish/3.1.1BuildSchedule, for marking the fixed in with appropriate 3.1.1 build #.

Comment by marina vatkina [ 19/Apr/11 ]

Fixed in 3.1.1 b03 with rev 46236

Comment by sherryshen [ 20/Apr/11 ]

Verified the fix on v3.2 b03 promoted.
Thank Marina for the fix.





[GLASSFISH-16361] AMX QL failures on AIX Created: 15/Apr/11  Updated: 02/Nov/11  Resolved: 27/May/11

Status: Resolved
Project: glassfish
Component/s: amx
Affects Version/s: 3.1.1_b01
Fix Version/s: 3.1.1_b03

Type: Bug Priority: Blocker
Reporter: Bhakti Mehta 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-approved

 Description   

We are getting AMX failures for QL on 3.1.1 on aix. Also we have noticed it crashes the server on AIX so I have moved those QL to the end.
Naman/Mahesh are looking in this. Filing bugs so QA can keep track of issues

Waiting for domain1 to start .............Error starting domain domain1.
The server exited prematurely with exit code 160.
Before it died, it produced the following output:

Launching GlassFish on Felix platform
Unhandled exception
Type=Illegal instruction vmState=0x00000000
J9Generic_Signal_Number=00000010 Signal_Number=00000004 Error_Value=00000000 Signal_Code=0000001e
Handler1=09001000A0262450 Handler2=09001000A0258F70
R0=0000000000000000 R1=00000001101159F0 R2=0000000000000000 R3=0000000110115B60
R4=0000000000000000 R5=000000000000002D R6=0900000000510780 R7=0000000000000000
R8=0000000010000102 R9=0000000010000102 R10=0000000114C34FE0 R11=0000000000000000
R12=09000000010AE5A4 R13=000000011011F800 R14=0000000000000000 R15=0000000000000011
R16=0000000000000018 R17=0000000000000018 R18=0000000000000011 R19=0000000000000275
R20=0000000112507DA8 R21=000000000000002D R22=0000000000000000 R23=09001000A024BD68
R24=0000000110AF25C8 R25=0000000000000000 R26=0000000111E78508 R27=0000000111E78500
R28=0000000110135308 R29=0000000000000000 R30=0000000000000000 R31=0000000000000000
IAR=0000000000000000 LR=09000000007213D0 MSR=A00000000000D032 CTR=0000000000000000
CR=8200202B20000000 FPSCR=8200000000000000 XER=2000000082000000
FPR0 fff80000000000c0 (f: 192.000000, d: -NaNQ)
FPR1 c1e0000000000000 (f: 0.000000, d: -2.147484e+09)
FPR2 4068000000000000 (f: 0.000000, d: 1.920000e+02)
FPR3 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
FPR4 3fe8000000000000 (f: 0.000000, d: 7.500000e-01)
FPR5 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
FPR6 4068000000000000 (f: 0.000000, d: 1.920000e+02)
FPR7 4070000000000000 (f: 0.000000, d: 2.560000e+02)
FPR8 3fe8000000000000 (f: 0.000000, d: 7.500000e-01)
FPR9 4070000000000000 (f: 0.000000, d: 2.560000e+02)
FPR10 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR11 3fe8000000000000 (f: 0.000000, d: 7.500000e-01)
FPR12 4070000000000000 (f: 0.000000, d: 2.560000e+02)
FPR13 4068000000000000 (f: 0.000000, d: 1.920000e+02)
FPR14 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR15 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR16 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR17 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR18 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR19 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR20 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR21 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR22 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR23 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR24 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR25 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR26 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR27 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR28 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR29 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR30 0000000000000000 (f: 0.000000, d: 0.000000e+00)
FPR31 0000000000000000 (f: 0.000000, d: 0.000000e+00)
Target=2_40_20090923_042924 (AIX 6.1)
CPU=ppc64 (2 logical CPUs) (0xfa000000 RAM)
----------- Stack Backtrace -----------
/usr/java6_64/jre/lib/ppc64/default/libj9vm24.so:0x00721380 [0x0071F000 +0x00002380]
/usr/java6_64/jre/lib/ppc64/default/libj9vm24.so:0x00720BFC [0x0071F000 +0x00001BFC]
/usr/java6_64/jre/lib/ppc64/default/libjclscar_24.so:0x010AE5BC [0x010A1000 +0x0000D5BC]
/usr/java6_64/jre/lib/ppc64/default/libjclscar_24.so:0x010FA390 [0x010A1000 +0x00059390]
0x10BDEBAC
/usr/java6_64/jre/lib/ppc64/default/libjvm.so:0x006FE468 [0x006F5000 +0x00009468]
/usr/java6_64/jre/lib/ppc64/libjava.so:0x008192CC [0x00802000 +0x000172CC]
0x10B6C870
/usr/java6_64/jre/lib/ppc64/default/libjvm.so:0x006FE468 [0x006F5000 +0x00009468]
/usr/java6_64/jre/lib/ppc64/libjava.so:0x008192CC [0x00802000 +0x000172CC]
0x10B6C870
/usr/java6_64/jre/lib/ppc64/default/libj9vm24.so:0x00731910 [0x0071F000 +0x00012910]
/usr/java6_64/jre/lib/ppc64/default/libj9vm24.so:0x00731BC0 [0x0071F000 +0x00012BC0]
/usr/java6_64/jre/lib/ppc64/default/libj9prt24.so:0x007BE984 [0x007BB000 +0x00003984]
/usr/java6_64/jre/lib/ppc64/default/libj9vm24.so:0x00731A74 [0x0071F000 +0x00012A74]
/usr/java6_64/jre/lib/ppc64/default/libj9vm24.so:0x00731FBC [0x0071F000 +0x00012FBC]
/usr/java6_64/jre/lib/ppc64/default/libj9vm24.so:0x00736864 [0x0071F000 +0x00017864]
java:0x00001448 [0x00000000 +0x00001448]
/usr/lib/libpthreads.a:0x004E7C94 [0x004E4000 +0x00003C94]
0x00000000
---------------------------------------
JVMDUMP006I Processing dump event "gpf", detail "" - please wait.
JVMDUMP032I JVM requested System dump using '/export/bhakti/tempGF2/glassfish3/glassfish/domains/domain1/config/core.20110413.231641.344242.0001.dmp' in response to an event
Note: "Enable full CORE dump" in smit is set to FALSE and as a result there will be limited threading information in core file.
JVMDUMP010I System dump written to /export/bhakti/tempGF2/glassfish3/glassfish/domains/domain1/config/core.20110413.231641.344242.0001.dmp
JVMDUMP032I JVM requested Snap dump using '/export/bhakti/tempGF2/glassfish3/glassfish/domains/domain1/config/Snap.20110413.231641.344242.0002.trc' in response to an event
JVMDUMP010I Snap dump written to /export/bhakti/tempGF2/glassfish3/glassfish/domains/domain1/config/Snap.20110413.231641.344242.0002.trc
JVMDUMP032I JVM requested Java dump using '/export/bhakti/tempGF2/glassfish3/glassfish/domains/domain1/config/javacore.20110413.231641.344242.0003.txt' in response to an event
JVMDUMP010I Java dump written to /export/bhakti/tempGF2/glassfish3/glassfish/domains/domain1/config/javacore.20110413.231641.344242.0003.txt
JVMDUMP013I Processed dump event "gpf", detail "".

[testng] ... Removed 22 stack frames
[testng] FAILED: createChildTest
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXConfigProxyTests.createChildTest(AMXConfigProxyTests.java:461)
[testng] ... Removed 22 stack frames
[testng] FAILED: createProfilerTest
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXConfigProxyTests.getServerConfig(AMXConfigProxyTests.java:512)
[testng] at amxtest.AMXConfigProxyTests.createProfilerTest(AMXConfigProxyTests.java:518)
[testng] ... Removed 22 stack frames
[testng] FAILED: connectorConnectionPoolTest
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXConfigProxyTests.getResources(AMXConfigProxyTests.java:92)
[testng] at amxtest.AMXConfigProxyTests.connectorConnectionPoolTest(AMXConfigProxyTests.java:499)
[testng] ... Removed 22 stack frames
[testng] FAILED: testCreateProperty
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXConfigProxyTests.testCreateProperty(AMXConfigProxyTests.java:270)
[testng] ... Removed 22 stack frames
[testng] FAILED: testAMXConfigDefaultValues
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXTestBase.getAllDescendents(AMXTestBase.java:433)
[testng] at amxtest.AMXTestBase.getAllConfig(AMXTestBase.java:441)
[testng] at amxtest.AMXConfigProxyTests.testAMXConfigDefaultValues(AMXConfigProxyTests.java:179)
[testng] ... Removed 22 stack frames
[testng] FAILED: testAMXConfigAttributeResolver
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXTestBase.getAllDescendents(AMXTestBase.java:433)
[testng] at amxtest.AMXTestBase.getAllConfig(AMXTestBase.java:441)
[testng] at amxtest.AMXConfigProxyTests.testAMXConfigAttributeResolver(AMXConfigProxyTests.java:188)
[testng] ... Removed 22 stack frames
[testng] FAILED: testAmxPref
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXConfigProxyTests.testAmxPref(AMXConfigProxyTests.java:378)
[testng] ... Removed 22 stack frames
[testng] FAILED: testCreateResource
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXConfigProxyTests.testCreateResource(AMXConfigProxyTests.java:336)
[testng] ... Removed 22 stack frames
[testng] FAILED: testCreateProperties
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXConfigProxyTests.testCreateProperties(AMXConfigProxyTests.java:408)
[testng] ... Removed 22 stack frames
[testng] FAILED: testConfigTools
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXConfigProxyTests.testConfigTools(AMXConfigProxyTests.java:198)
[testng] ... Removed 22 stack frames
[testng] FAILED: testConnectorRuntimeAPIProvider
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXOtherTests.testConnectorRuntimeAPIProvider(AMXOtherTests.java:92)
[testng] ... Removed 22 stack frames
[testng] FAILED: testVariousGetters
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXOtherTests.testVariousGetters(AMXOtherTests.java:99)
[testng] ... Removed 22 stack frames
[testng] FAILED: testBulkAccess
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testBulkAccess(AMXProxyTests.java:218)
[testng] ... Removed 22 stack frames
[testng] FAILED: testChildGetterVariants
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXTestBase.findAllContainingType(AMXTestBase.java:418)
[testng] at amxtest.AMXProxyTests.testChildGetterVariants(AMXProxyTests.java:553)
[testng] ... Removed 22 stack frames
[testng] FAILED: testServers
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testServers(AMXProxyTests.java:308)
[testng] ... Removed 22 stack frames
[testng] FAILED: testDomainConfig
[testng] java.lang.AssertionError: _testProxyInterface(): null proxy for class org.glassfish.admin.amx.intf.config.Domain
[testng] at amxtest.AMXProxyTests._testProxyInterface(AMXProxyTests.java:105)
[testng] at amxtest.AMXProxyTests.testProxyInterface(AMXProxyTests.java:98)
[testng] at amxtest.AMXProxyTests.testDomainConfig(AMXProxyTests.java:273)
[testng] ... Removed 22 stack frames
[testng] FAILED: testSingletonOrNot
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testSingletonOrNot(AMXProxyTests.java:468)
[testng] ... Removed 22 stack frames
[testng] FAILED: testQuery
[testng] java.lang.AssertionError: _testProxyInterface(): null proxy for class org.glassfish.admin.amx.base.Query
[testng] at amxtest.AMXProxyTests._testProxyInterface(AMXProxyTests.java:105)
[testng] at amxtest.AMXProxyTests.testProxyInterface(AMXProxyTests.java:98)
[testng] at amxtest.AMXProxyTests.testQuery(AMXProxyTests.java:212)
[testng] ... Removed 22 stack frames
[testng] FAILED: testApplications
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testApplications(AMXProxyTests.java:283)
[testng] ... Removed 22 stack frames
[testng] FAILED: testAutoConvert
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testAutoConvert(AMXProxyTests.java:402)
[testng] ... Removed 22 stack frames
[testng] FAILED: testPropertyParent
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXTestBase.findAllContainingType(AMXTestBase.java:418)
[testng] at amxtest.AMXProxyTests.testPropertyParent(AMXProxyTests.java:315)
[testng] ... Removed 22 stack frames
[testng] FAILED: testPathnames
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testPathnames(AMXProxyTests.java:266)
[testng] ... Removed 22 stack frames
[testng] FAILED: testSystemInfo
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testSystemInfo(AMXProxyTests.java:254)
[testng] ... Removed 22 stack frames
[testng] FAILED: testExt
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXTestBase.getExt(AMXTestBase.java:321)
[testng] at amxtest.AMXProxyTests.testExt(AMXProxyTests.java:206)
[testng] ... Removed 22 stack frames
[testng] FAILED: testLogging
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testLogging(AMXProxyTests.java:260)
[testng] ... Removed 22 stack frames
[testng] FAILED: testTools
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testTools(AMXProxyTests.java:224)
[testng] ... Removed 22 stack frames
[testng] FAILED: testRuntimeRoot
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testRuntimeRoot(AMXProxyTests.java:236)
[testng] ... Removed 22 stack frames
[testng] FAILED: testSystemApplications
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testSystemApplications(AMXProxyTests.java:302)
[testng] ... Removed 22 stack frames
[testng] FAILED: testServerRuntime
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testServerRuntime(AMXProxyTests.java:242)
[testng] ... Removed 22 stack frames
[testng] FAILED: testSystemPropertyParent
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXTestBase.findAllContainingType(AMXTestBase.java:418)
[testng] at amxtest.AMXProxyTests.testSystemPropertyParent(AMXProxyTests.java:329)
[testng] ... Removed 22 stack frames
[testng] FAILED: testAllGenerically
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testAllGenerically(AMXProxyTests.java:441)
[testng] ... Removed 22 stack frames
[testng] FAILED: testConfigs
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testConfigs(AMXProxyTests.java:296)
[testng] ... Removed 22 stack frames
[testng] FAILED: testJ2EEDomain
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testJ2EEDomain(AMXProxyTests.java:566)
[testng] ... Removed 22 stack frames
[testng] FAILED: testMonitoringRoot
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testMonitoringRoot(AMXProxyTests.java:230)
[testng] ... Removed 22 stack frames
[testng] FAILED: testDomainRoot
[testng] java.lang.AssertionError: _testProxyInterface(): null proxy for class org.glassfish.admin.amx.base.DomainRoot
[testng] at amxtest.AMXProxyTests._testProxyInterface(AMXProxyTests.java:105)
[testng] at amxtest.AMXProxyTests.testProxyInterface(AMXProxyTests.java:98)
[testng] at amxtest.AMXProxyTests.testDomainRoot(AMXProxyTests.java:189)
[testng] ... Removed 22 stack frames
[testng] FAILED: testSystemStatus
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testSystemStatus(AMXProxyTests.java:385)
[testng] ... Removed 22 stack frames
[testng] FAILED: testResources
[testng] java.lang.NullPointerException
[testng] at amxtest.AMXProxyTests.testResources(AMXProxyTests.java:289)
[testng] ... Removed 22 stack frames
[testng] SKIPPED: iterateAllSanityCheck
[testng]
[testng] ===============================================
[testng] amx_tests
[testng] Tests run: 43, Failures: 38, Skips: 1
[testng] ===============================================



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

This has been fixed. We now use Flashlight to instrument probe providers

Comment by Mahesh Kannan [ 02/Nov/11 ]

This has been fixed long back





[GLASSFISH-16316] System properties with variables in them should not be expanded/replaced in the UI Created: 05/Apr/11  Updated: 22/Apr/11  Resolved: 22/Apr/11

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b03

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

redhat enterprise 6.0


Attachments: File 16316.diff    
Tags: 3-1_next, 3_1_1-approved

 Description   

With Glassfish 3.1 b43, when I create a system property that includes a system property inside it, it is expanded in the UI, but seems to be stored correctly in domain.xml.
Create a system property named whatever.
Set it's value to "$

{com.sun.aas.instanceRoot}

/config/cluster1-config/app.properties"
Save the changes.
It will display as "/glassfish-install-location/glassfish/domains/domain1/config/cluster1-config/app.properties" It should display with the ${} syntax, and not replace it with the domain's value.

This is especially confusing when you're using the admin gui to set up a cluster's config and it replaces the variable with the value for domain1.



 Comments   
Comment by Anissa Lam [ 05/Apr/11 ]

Admin console uses REST API to get the information, and the property value has already been 'evaluated' before it gets back to the console.
Some info for Jason to reproduce the case.

  • in the console, go to server-config->System Properties. Create a system property with name=TEST and value=$ {ccom.sun.aas.instanceRoot}

    /foo

  • Save.

This is persisted correctly in domain.xml, and in CLI, you can see that the value is returned exactly like what you filled in.

%asadmin get server.system-property.TEST
server.system-property.TEST.name=TEST
server.system-property.TEST.value=$

{com.sun.aas.instanceRoot}

/foo
Command get executed successfully.

But doing
http://localhost:4848/management/domain/configs/config/server-config/system-properties.json
will give
{"exit_code":"SUCCESS","extraProperties":{"systemProperties":[

{"name":"TEST","value":"\/Users\/anilam\/Awork\/V3\/v3\/dist-gf\/glassfish\/domains\/domain1\/foo"}

]}}

thats why console is showing the resolved value.
I think this needs to be fixed. Otherwise user has to change this back to the variable everytime they need to edit the properties.

Comment by Jason Lee [ 22/Apr/11 ]

The problem here is that the hidden CLI created to perform this operation deals with SystemPropertiesBag objects, which appear to resolve the tokens to their values. The solution, then, seems to be to remove that code and deal only with the HK2 Dom objects (which is what the get command does). I've made that change and created tests that verify the correct behavior for DAS, standalone instance, cluster, and clustered instance system properties. The diff is attached for 3.1.1 review.

Comment by Jason Lee [ 22/Apr/11 ]
  • Why fix this issue in 3.1.1?
    • As I understand it, this is a regression from v3
  • Which is the targeted build of 3.1.1 for this fix?
    • b03
  • Do regression tests exist for this issue?
    • The diff attached adds regression tests
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    • The SystemPropertiesTest test suite in the REST dev tests should be sufficient (though the related Admin Console tests might also be appropriate)
Comment by ludo [ 22/Apr/11 ]

Change seems good. I like to extensive test case...
I guess, the console tests are fine as well...

Comment by Jason Lee [ 22/Apr/11 ]

Fix committed to trunk. Branch commit approval still pending.

Comment by scatari [ 22/Apr/11 ]

Approved.

Comment by Jason Lee [ 22/Apr/11 ]

Fix committed to the branch.





[GLASSFISH-16209] when accessing simple secure webapp on 3.1 cluster with iWS and LBplugin frontend, it get redirect and expose the GF https instances url. Created: 14/Mar/11  Updated: 28/Apr/11  Resolved: 28/Apr/11

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

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

On OEL with iws 7.0.9 with LB b05


Attachments: File WebApplication.war    
Tags: 3_1_1-review

 Description   

When you deploy a simple secure webapp on a v3.1 cluster with iPlanet WebServer with LB plugin frontend, and access the webapp using HTTPS, it redirected to GF instance HTTPS port. In this setup, neither HTTPS Routing not authPassThrough is enabled. With this its exposing the GF instance to the client.

For ex: When I access https://webserver_host/WebApplliaction/index.jsp it redirects to https:gf_instancehost_port/WebApplciation/index.jsp.

Because of the SSL offloading, the HTTPS request from client is forwarded by the LB to the HTTP port of the GF instance. Its reasonable that GF instance sees this request as received on unsecure port and redirects to secure port. But it should have redirected to the WebServer HTTPs port using the Host header in the incoming request.

As per analysis done by Kshitiz, GF instance seems to use the host name from Host header, However ssl port for instance is appended to it which is incorrect.



 Comments   
Comment by Shing Wai Chan [ 14/Mar/11 ]

Assign to load balancer team for evaluation.

Comment by ramapulavarthi [ 14/Mar/11 ]

Apart from fixing the issue to use the correct port (https port) of the web server, I think the fix has to go little farther to provide insight into the problem to the user. As neither HTTPS Routing not authPassThrough is enabled, redirecting to webserver https port in this case would keep the client in loop as the new redirect location is the same as the original url client used.

Client ---> https://webserver/App ---->http:gf_instance/App

<--- https://webserver/App <---HTTP 302

---->
If possible, the implementation can try to be little smart in detecting this scenario and suggest the user with an error page that suggests enabling HTTPS Routing on LB or authPassThrough on cluster.

Comment by kshitiz_saxena [ 14/Mar/11 ]

Load-balancer code should not kick in when redirection is from SSL to non-SSL OR non-SSL to SSL. User must set "rewrite-location" to "false" in load-balancer xml for such scenarios.

The web-container must handle this scenario of redirection. As mentioned in description, it uses "Host" header correctly when creating redirect url. However it appends SSL listener port to it, resulting in this issue. The web-container code should detect whether "Host" header in request was pointing to its non-SSL listener.
=>If yes, then redirect should to be to its SSL listener.
=>If no, then it should use the url from "Host" header, and only update the protocol,i.e., from http to https in this case.

Reassigning it back to web-container team.

Comment by Shing Wai Chan [ 16/Mar/11 ]

The redirection logic is in security module. Reassign to security team.

Comment by Nithya Ramakrishnan [ 19/Apr/11 ]

Why fix this issue in 3.1.1?
This fix impacts product security and must be fixed.

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

Do regression tests exist for this issue?
SQE security test - appserver-sqe/pe/security/ssl/redirectport

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
QA(Jothir and Varun) are writing up tests for the specific issue.

Comment by scatari [ 19/Apr/11 ]

Does it apply only to 3.1.1?

Since you haven't fixed it yet(correct me if I am wrong),the build # should be 3.1.1_02. Please refer here for build schedule. http://wikis.sun.com/display/GlassFish/3.1.1BuildSchedule

Comment by Nithya Ramakrishnan [ 21/Apr/11 ]

Changing the target build

Comment by Nithya Ramakrishnan [ 21/Apr/11 ]

This applies to 3.2 as well. The fix has already been checked in into the trunk. (after the 3.1.1 branching).
This request is to checkin into the 3.1.1 branch.

Yes, the target build should be the next one - changed it to 3.1.1_03

Comment by Nithya Ramakrishnan [ 28/Apr/11 ]

Fixed in the 3.1.1 branch and trunk





[GLASSFISH-16192] lookup fails for JMS Connection factory from java web start client Created: 10/Mar/11  Updated: 28/Mar/13  Resolved: 14/Apr/11

Status: Closed
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b03 , 4.0_b01

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

linux glassfish 3.1 java se 6u24


Attachments: Zip Archive JMS_JWS_Tester.zip     Text File verbose.txt    
Tags: 3_1_1-approved

 Description   

I have a simple test client that I am trying to use to connect to JMS on glassfish 3.1. The application server has a simple connection factory created with:

asadmin create-jms-resource --restype javax.jms.ConnectionFactory jms/TestConnectionFactory

And the code I try to connect with is:

InitialContext jndiContext = new InitialContext();

jndiContext.lookup("jms/TestConnectionFactory");

This fails with the craziest stack trace. If I run it as an appclient directly it works fine. But when I run it as a java web start it fails.

I have attached the zip of setup of mvn projects that should be easy to build and deploy on glassfish 3.1. other than that I just ran the asadmin commands to create the connection

The stack trace I get is:

Mar 10, 2011 5:50:54 PM com.sun.enterprise.connectors.ActiveOutboundResourceAdapter init
SEVERE: RAR6035 : Resource adapter start failed :

{0}

java.lang.NoClassDefFoundError: com/sun/messaging/jmq/jmsserver/util/BrokerException
at com.sun.messaging.jms.ra.ResourceAdapter.start(ResourceAdapter.java:356)
at com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter$1.run(ActiveJmsResourceAdapter.java:360)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter.startResourceAdapter(ActiveJmsResourceAdapter.java:353)
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:129)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.init(ActiveInboundResourceAdapterImpl.java:90)
at com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(ActiveRAFactory.java:135)
at com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:106)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:212)
at com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:378)
at com.sun.enterprise.resource.naming.ConnectorObjectFactory.getObjectInstance(ConnectorObjectFactory.java:108)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:556)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:514)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.tester.client.Main.main(Main.java:35)
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.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:432)
at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
at org.glassfish.appclient.client.JWSAppClientContainerMain$ClientRunner.run(JWSAppClientContainerMain.java:168)
at org.glassfish.appclient.client.JWSAppClientContainerMain.main(JWSAppClientContainerMain.java:132)
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.javaws.Launcher.executeApplication(Launcher.java:1804)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1750)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1512)
at com.sun.javaws.Launcher.run(Launcher.java:130)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: com.sun.messaging.jmq.jmsserver.util.BrokerException
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 com.sun.jnlp.JNLPClassLoader.findClass(JNLPClassLoader.java:332)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 34 more
Mar 10, 2011 5:50:54 PM com.tester.client.Main main
SEVERE: Lookup failed for 'jms/TestConnectionFactory' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}
javax.naming.NamingException: Lookup failed for 'jms/TestConnectionFactory' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NamingException: Failed to look up ConnectorDescriptor from JNDI [Root exception is com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Failed to start resource adapter : com/sun/messaging/jmq/jmsserver/util/BrokerException]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.tester.client.Main.main(Main.java:35)
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.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:432)
at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
at org.glassfish.appclient.client.JWSAppClientContainerMain$ClientRunner.run(JWSAppClientContainerMain.java:168)
at org.glassfish.appclient.client.JWSAppClientContainerMain.main(JWSAppClientContainerMain.java:132)
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.javaws.Launcher.executeApplication(Launcher.java:1804)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1750)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1512)
at com.sun.javaws.Launcher.run(Launcher.java:130)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.naming.NamingException: Failed to look up ConnectorDescriptor from JNDI [Root exception is com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Failed to start resource adapter : com/sun/messaging/jmq/jmsserver/util/BrokerException]
at com.sun.enterprise.resource.naming.ConnectorObjectFactory.getObjectInstance(ConnectorObjectFactory.java:115)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:556)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:514)
... 20 more
Caused by: com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Failed to start resource adapter : com/sun/messaging/jmq/jmsserver/util/BrokerException
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:140)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.init(ActiveInboundResourceAdapterImpl.java:90)
at com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(ActiveRAFactory.java:135)
at com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:106)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:212)
at com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:378)
at com.sun.enterprise.resource.naming.ConnectorObjectFactory.getObjectInstance(ConnectorObjectFactory.java:108)
... 23 more
Caused by: java.lang.ClassNotFoundException: com.sun.messaging.jmq.jmsserver.util.BrokerException
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 com.sun.jnlp.JNLPClassLoader.findClass(JNLPClassLoader.java:332)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at com.sun.messaging.jms.ra.ResourceAdapter.start(ResourceAdapter.java:356)
at com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter$1.run(ActiveJmsResourceAdapter.java:360)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.enterprise.connectors.jms.system.ActiveJmsResourceAdapter.startResourceAdapter(ActiveJmsResourceAdapter.java:353)
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:129)
... 29 more



 Comments   
Comment by Tim Quinn [ 11/Mar/11 ]

Short diagnosis: BrokerException is in imqbroker.jar (from glassfish3/mq/lib in the GlassFish installation). That JAR is not among the many we tell Java Web Start might be needed by a client, so that causes the NoClassDefFound exception.

Longer story: The JARs we tell Java Web Start might be needed are all the JARs listed in the gf-client.jar manifest Class-Path setting. The app client container does not itself access many of those JARs, so the build for the app client container explicitly adds maven dependencies or other updates to the Class-Path setting (for non-maven JARs). We never added imqbroker.jar to the list because the MQ doc does not list it as a JAR needed for clients.

I am talking with the MQ team about this.

Comment by gcruscoe [ 15/Mar/11 ]

After some experimentation I have modified maven to bring in imqbroker.jar as a dependency. It is now getting bundled into the lib directory of the ear. The stand alone java web start client then pulls it down on its own and therefore it does not fail. In addition I had to deploy the jar as a maven artifact to our local maven server in order to make this work as I didn't find any references to imqbroker.jar being available via the external maven repos.

However, I am not sure that this is the correct fix for this. It seems to me that if it is part of glassfish and compiles using the gfclient or the javax.javaee-api maven dependencies that it should not need the extra dependency (where I use compile instead of provided scope) so that this one piece will be included. In addition, I am a little concerned about the practice of including imqbroker.jar in the ear's lib directory. If I am not mistaken it will NOT be used by anything because the class loader will pick up the one from the app server's lib directory first, but still doesn't seem right.

Hoping I can get some official word on whether the fix is safe and or recommended as well as whether there would be a plan to modify the standalone client components so that jms can be used without additional steps.

Thanks!

Comment by Tim Quinn [ 15/Mar/11 ]

Certainly users should not have to bundle a GlassFish or MQ/JMS JAR file into their applications.

There would seem to be no inherent problem in bundling imqbroker.jar into your app (except for enlarging your app) as a workaround.

It's not yet clear what the eventual fix from GlassFish should be. Perhaps BrokerException should not even be in the picture here. Perhaps it's OK for BrokerException to be involved but it might migrate to another JAR. Or perhaps imqbroker.jar needs to be added to the downloaded files for Java Web Start launches of app clients. Or there could be some other fix altogether.

We're working on it.

Comment by Tim Quinn [ 15/Mar/11 ]

Just for completeness, here are the commands I used to set up the cnx factory and the topic:

asadmin create-jms-resource --restype=javax.jms.TopicConnectionFactory --description="topic connection factory for bug" jms/TestConnectionFactory

asadmin create-jms-resource --restype=javax.jms.Topic --description="JMS Topic for bug" jms/Topic

And, with the change in my workspace to include imqbroker.jar in the Java Web Start downloaded JARs, launching the client using

javaws "http://localhost:8080/tester/Tester-client-jms"

worked - the client was able to find and use the connection factory and subscribe to the topic.

(and mvn worked fine to build the example app - thanks for providing it)

Comment by Tim Quinn [ 16/Mar/11 ]

I've attached verbose.txt which contains the -verbose:class output from a Java Web Start launch which culminates in the class not found error for BrokerException. There is a lot of data there but the ending part might be helpful.

Comment by Nigel Deakin [ 17/Mar/11 ]

This looks like a bug in the JMSRA resource adapter, which has introduced a dependency on BrokerException (and hence imqbroker.jar) which was not there previously.

I've logged this as MQ issue 80:
http://java.net/jira/browse/MQ-80

and assigned that issue, and this one, to me.

Comment by Nigel Deakin [ 17/Mar/11 ]

The underlying MQ issue (http://java.net/jira/browse/MQ-80) has now been fixed and will be released in MQ 4.6 b1.

This GlassFish issue will therefore be fixed in the first GlassFish build which contains it, which is expected to be GF 3.2 b1.

This issue affects all application clients run using Java Web Start which use MQ. Thank you to the person who reported it.

Comment by gcruscoe [ 17/Mar/11 ]

Glad to help out! Thanks for figuring this out!

Comment by Nigel Deakin [ 08/Apr/11 ]

Since the target version has been changed from 3.2 to 3.1.1 this will require backporting the underlying MQ fix from MQ 4.6 (which goes into 3.2) to MQ 4.5.1 (which goes into 3.1.1). Since this requires action, I'll reopen the bug.

Comment by Nigel Deakin [ 14/Apr/11 ]

I believe that the Fix Version/s field was changed from 3.2 to 3.1.1 in the mistaken belief that the fix had already been ported to 3.1.1, rather than an explicit request to perform the backport. I have therefore corrected the Fix version/s field and marked the bug as resolved. If a backport is required, please add a comment stating exactly what is required and re-open the bug.

Comment by Nigel Deakin [ 03/May/11 ]

A fix to MQ-80 has now been ported to MQ 4.5.1_b01. This release will be included in GlassFish 3.1_b03. I am therefore recording this bug as being fixed in GlassFish 3.1.1_b03 as well as GlassFish 3.2_b01.

Comment by Nigel Deakin [ 03/May/11 ]

Adding (retrospectively) the 3_1_1-review tag to ensure that this fix is properly reviewed as being suitable for 3.1.1.

This bug was introduced in GlassFish 3.1 and affects all application clients run using Java Web Start which use MQ. Although the bug is caused by missing classes in the classpath, a user using JWS does not have direct control over the classpath and so cannot easily work around it.

The targetted build for this fix is 3.1_b03 (as stated in the previous comment).

There are no regression tests for this issue but it is very easy to reproduce using the steps above and verify.

The fix itself is very simple and the risk of accidentally destabilising GlassFish is very low.

Comment by Nigel Deakin [ 28/Mar/13 ]

Closing this issue as it has now been resolved, and no additional testing is required.





[GLASSFISH-15711] The Default Provider checkbox is displaying wrong info and was ignored when creating/saving the provider config. Created: 27/Jan/11  Updated: 25/Apr/11  Resolved: 25/Apr/11

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

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

Tags: 3_1_1-approved

 Description   

The defaultProvider checkbox in Provider Config is wrong.
The logic of calculating the value is wrong.

gf.getEntityAttrs(endpoint="#

{sessionScope.REST_URL}

/configs/config/#

{pageSession.configName}

/security-service/message-security-config/#

{pageSession.msgSecurityName}

.json",
valueMap="#

{pageSession.msgSecurityMap}

");
mapPut(map="#

{pageSession.valueMap}" key="defaultProvider" value="false");

if ("#{pageSession.msgSecurityMap['defaultClientProvider']}=true || #{pageSession.msgSecurityMap['defaultProvider']}=true")
mapPut(map="#{pageSession.valueMap}

" key="defaultProvider" value="true");

It should test the name of the defaultClientProvider and defaultProvider and see if it match the one you are trying to edit.

There is no code to save this checkbox value also.

Since it is too late to fix and add the logic, I am removing the checkbox for 3.1.
User can select that to be the default in the MessageSecurity page itself.

Filing this but exclude from 3.1



 Comments   
Comment by srinik76 [ 08/Mar/11 ]

Hi Anissa,

I am looking into Issue 15711 (http://java.net/jira/browse/GLASSFISH-15711), my observation

1. Adding a provider under Provider Configurations works fine.
2. While editing a provider under Provider Configuration the checkbox is removed, I need to add the check box and add the logic so that if the checkbox is selected, this needs to be added as default-provider under this provider.

Please confirm if my comment is fine before I start working on this.

Regards
Srinivas

Comment by srinik76 [ 10/Mar/11 ]

Checked in the fix.

Reintroduced the checkbox and implemented the save functionality during editing

Sending common/src/main/java/org/glassfish/admingui/common/handlers/SecurityHandler.java
Sending common/src/main/resources/security/msgSecurity/providerAttr.inc
Sending common/src/main/resources/security/msgSecurity/providerEdit.jsf
Transmitting file data ...
Committed revision 45463.

Comment by srinik76 [ 10/Mar/11 ]

Checked in the fix and closing the bug.

Comment by Anissa Lam [ 04/Apr/11 ]

Reopen the bug as this introduce regression of saving ProviderConfig.

Step to reproduce:

  • create a Provider Config, take all the default and fill in the following:
    provider ID: TEST
    Classname: test.test
  • after creation, go to edit this Provider Config. No need to change anything, just press 'Save'.

Exception occurs, and you see "An error has occurred" in the GUI screen
In server.log, it says:

[#|2011-04-04T22:32:09.687-0700|INFO|glassfish3.2|org.glassfish.admingui|_ThreadID=23;_ThreadName=admin-thread-pool-4848(5);|Exception Occurred :null|#]

Comment by srinik76 [ 25/Apr/11 ]

Checked in the fix in the trunk

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

Comment by srinik76 [ 25/Apr/11 ]
  • Why fix this issue in 3.1.1?
    o In a newly created config, after creating a provider trying to edit fails with error
  • Which is the targeted build of 3.1.1 for this fix?
    o Next build (The fix has been checked in the trunk, just need to backport the change to the branch.)
  • Do regression tests exist for this issue?
    o A test has been added in SecurityTest
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    o console devtest should be sufficient
Comment by scatari [ 25/Apr/11 ]

Approved. Please update the "Fix in version" appropriately.

Comment by srinik76 [ 25/Apr/11 ]

Checked in the fix into branch v3.1.1

Sending SecurityHandler.java
Transmitting file data .
Committed revision 46444.

Comment by srinik76 [ 25/Apr/11 ]

Closing the issue as fixed

Comment by srinik76 [ 25/Apr/11 ]

Checked in the test case into the branch v3.1.1

Sending SecurityTest.java
Transmitting file data .
Committed revision 46445.

Comment by srinik76 [ 25/Apr/11 ]

Need to add the fix version 3.2_b03

Comment by srinik76 [ 25/Apr/11 ]

Added the fix version 3.2_b03





Generated at Tue Sep 01 07:34:00 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.