### [WSIT-1523] java.lang.IllegalStateException: Transaction null does not exist Created: 21/Jan/11  Updated: 31/May/12  Resolved: 31/May/12

Status: Resolved
Project: wsit
Component/s: transaction
Affects Version/s: 2.1
Fix Version/s: None

 Type: Bug Priority: Major Reporter: Sreekanth Assignee: arjavdesai Resolution: Invalid Votes: 1 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: glassfish 3.1

 Attachments: b.out     server.log     TxAppMandatory.zip Tags: 3_1-release-notes, metro2_1-waived, metro2_2-waived

 Description

This issue is in continuation to http://java.net/jira/browse/WSIT-1522

Once we create a directory with name null on the place where we run appclient, now we see transactions are not flowed.

Exception at server side:

avax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=50;_ThreadName=Thread-1;|com.sun.xml.ws.tx.at.WSATException: java.lang.IllegalStateException: Transaction null does not exist, wsatResource=WSATXAResource: xidcom.sun.xml.ws.tx.at.internal.XidImpl@3132 status:ACTIVE epr:<?xml version="1.0" encoding="UTF-8" standalone="yes"?><EndpointReference xmlns="http://www.w3.org/2005/08/addressing"><Address>https://spidy:8181/__wstx-services/ParticipantPortType11</Address><ReferenceParameters><wsat-wsat:txId xmlns:ns2="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsat-wsat="http://com.sun.xml.ws.tx.at/ws/2008/10/wsat">4D2-3444322D333133323339333533363330333733333332333333343332333632443330</wsat-wsat:txId><wsat-wsat:routing xmlns:ns2="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsat-wsat="http://com.sun.xml.ws.tx.at/ws/2008/10/wsat">none</wsat-wsat:routing></ReferenceParameters><Metadata/></EndpointReference> isRemovedFromMap:false
at com.sun.xml.ws.tx.at.internal.TransactionServicesImpl.enlistResource(TransactionServicesImpl.java:99)
at com.sun.xml.ws.tx.coord.common.endpoint.BaseRegistration.enlistResource(BaseRegistration.java:161)
at com.sun.xml.ws.tx.coord.common.endpoint.BaseRegistration.processRegisterTypeAndEnlist(BaseRegistration.java:112)
at com.sun.xml.ws.tx.coord.common.endpoint.BaseRegistration.registerOperation(BaseRegistration.java:80)
at com.sun.xml.ws.tx.coord.v11.endpoint.RegistrationPortImpl.registerOperation(RegistrationPortImpl.java:80)
at sun.reflect.GeneratedMethodAccessor161.invoke(Unknown Source)
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)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:142)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:116)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:212)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:144)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:314) at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:608)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:259)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:162)
at org.glassfish.webservices.JAXWSServlet.doPost(JAXWSServlet.java:145)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
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:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.IllegalStateException: Transaction null does not exist, wsatResource=WSATXAResource: xidcom.sun.xml.ws.tx.at.internal.XidImpl@3132 status:ACTIVE epr:<?xml version="1.0" encoding="UTF-8" standalone="yes"?><EndpointReference xmlns="http://www.w3.org/2005/08/addressing"><Address>https://spidy:8181/__wstx-services/ParticipantPortType11</Address><ReferenceParameters><wsat-wsat:txId xmlns:ns2="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsat-wsat="http://com.sun.xml.ws.tx.at/ws/2008/10/wsat">4D2-3444322D333133323339333533363330333733333332333333343332333632443330</wsat-wsat:txId><wsat-wsat:routing xmlns:ns2="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsat-wsat="http://com.sun.xml.ws.tx.at/ws/2008/10/wsat">none</wsat-wsat:routing></ReferenceParameters><Metadata/></EndpointReference> isRemovedFromMap:false
at com.sun.xml.ws.tx.at.internal.WSATGatewayRM.registerWSATResource(WSATGatewayRM.java:234)
at com.sun.xml.ws.tx.at.internal.TransactionServicesImpl.enlistResource(TransactionServicesImpl.java:97)
... 62 more

 #]

 Comments
 Comment by Sreekanth [ 21/Jan/11 ] Client side invocation output Comment by Sreekanth [ 21/Jan/11 ] Netbeans application for the same Comment by Sreekanth [ 21/Jan/11 ] Steps to reproduce: 1)Unzip the attached netbeans application. 2)In command line "cd" to the place where you extracted the application. 3)Assuming the zip file is extraced to here: /home/sreekanth/NetBeansProjects/TxAppMandatory Now to build the tests do : bash:\> ant dist bash:\>asadmin deploy --retrieve dist --force=true dist/TxAppMandatory.ear bash:\>appclient -client dist/TxAppMandatoryClient.jar Make sure you have asadmin and ant in the Path. Comment by armanis [ 08/Aug/11 ] Problem persists after retesting against Glassfish 3.1.1 final, as expected I guess Comment by arjavdesai [ 31/May/12 ] AppClients are not supported with WS-AT as there is no JTA support in App client container. Only Web Client is supported. Comment by arjavdesai [ 31/May/12 ] We already have an enhancement request for the same WSIT-526

### [WSIT-1522] WSATGatewayRM.initStore path:null/../wsat/inbound/ Created: 21/Jan/11  Updated: 09/Oct/12  Resolved: 09/Jan/12

Status: Resolved
Project: wsit
Component/s: transaction
Affects Version/s: current
Fix Version/s: 2.2

 Type: Bug Priority: Major Reporter: Sreekanth Assignee: arjavdesai Resolution: Fixed Votes: 1 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Glassfish3.1

 Attachments: TxAppMandatory.zip Tags: 3_1-release-notes, glassfish-3-1, metro2_1-waived, metro2_2-waived, transactions, ws-at

 Description

### [GLASSFISH-16770] [asadmin] Unable to set "-server" JVM options Created: 31/May/11  Updated: 20/Dec/16  Resolved: 14/Dec/11

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

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

Issue Links:
 Duplicate is duplicated by GLASSFISH-17127 asadmin create-jvm-options "-server" Resolved is duplicated by GLASSFISH-18180 asadmin incorrectly parses -server as... Resolved
Tags: 3_1-next_release-note-added, 3_1-next_release-notes, 3_1-release-notes

 Description
 Just trying to change the JVM options with asadmin instead of writing XML: $./bin/asadmin create-jvm-options -server Deprecated syntax, instead use: asadmin --secure --echo create-jvm-options [options] ... ^^^ and there it hangs. The command doesn't return at all, neither success, nor failure. The following doesn't work either:$ ./bin/asadmin create-jvm-options "-server" $./bin/asadmin create-jvm-options '-server'$ ./bin/asadmin create-jvm-options -server However, as a current workaround, the following works: $./bin/asadmin create-jvm-options "-server" ...or:$ ./bin/asadmin create-jvm-options '-server'

 Comments
 Comment by ancoron [ 31/May/11 ] This JIRA just vanishes backslashes. Another try: The following doesn't work either: $./bin/asadmin create-jvm-options "-server"$ ./bin/asadmin create-jvm-options '-server' $./bin/asadmin create-jvm-options \-server  However, as a current workaround, the following works: $ ./bin/asadmin create-jvm-options "\-server"  ...or: $./bin/asadmin create-jvm-options '\-server'  Comment by Tom Mueller [ 31/May/11 ] The required syntax for setting a JVM option that looks like an asadmin short option is as follows: asadmin create-jvm-options – -server The "--" option causes asadmin to stop processing asadmin options and anything after it is considered a subcommand option. Comment by ancoron [ 31/May/11 ] Well, that is OK for the command part itself, but why does the command hang? Comment by ancoron [ 02/Jun/11 ] This should also be stated in the documentation, because it is not obvious that "-server" is an asadmin short option. Comment by Tom Mueller [ 08/Jun/11 ] Reopening this issue a docs bug to add a special comment to the create-jvm-options manual page about setting JVM options that look like asadmin short options. Comment by Tom Mueller [ 08/Jun/11 ] The create-jvm-options manual page should include a note about the interaction between some JVM options, such as "-server" and asadmin short options, such as "-s" and "-e" (for --secure and --echo). When creating a JVM option that starts with one of the asadmin short options, then it is necessary to cause asadmin to stop parsing its options by specifying the "--" option after the subcommand name, as in: asadmin create-jvm-options – -server Comment by Tom Mueller [ 08/Jun/11 ] Regarding the question about why the command appears to hang, the command doesn't actually hang. It attempts to make a secure connection to the server, but the connection eventually times out on the SSL handshake. If one waits long enough, the output is the following:$ asadmin create-jvm-options -server Deprecated syntax, instead use: asadmin --secure --echo create-jvm-options [options] ... It appears that server [localhost:4848] does not accept secure connections. Retry with --secure=false. javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake Command create-jvm-options failed. Regarding the parsing of "-server" as the short asadmin options -s and -e (with the -r and -v ignored), this problem is addressed by issue GLASSFISH-72. Comment by Paul Davies [ 08/Jul/11 ] Too late to fix in the man page for 3.1.1. Should be added to the Release Notes. Comment by Rebecca Parks [ 12/Jul/11 ] Added the following to the 3.1.1 Release Notes: Unable to set -server JVM options (16770) Description GlassFish Server misinterprets the following command: asadmin> create-jvm-options -server The command is interpreted as if the following command had been entered, using the short options for --secure and --echo: asadmin> create-jvm-options -se Workaround To specify a JVM option that could be mistaken for one or more asadmin command short options, use a double dash before the JVM option. For example: asadmin> create-jvm-options – -server This double dash tells the asadmin command to stop parsing its own short options and start parsing subcommand options. Comment by Paul Davies [ 18/Jul/11 ] I would like to keep this issue open to allow for the possibility of adding this information to the man page in a future release. Comment by Mike Fitch [ 14/Dec/11 ] Updated create-jvm-option in build 14 via svn commit 51521 Comment by Mike Fitch [ 14/Dec/11 ] Accidentally clicked "Close" instead of "Resolve" Comment by Mike Fitch [ 14/Dec/11 ] Clicking "Resolve" this time.

### [GLASSFISH-16385] Firefox 4.0 does not work for the Admin Console Targeting dialogs Created: 19/Apr/11  Updated: 25/Jul/11  Due: 19/Apr/11  Resolved: 19/Apr/11

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

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

 Attachments: ff5_gf_console_issue.jpg Tags: 3_1-release-note-added, 3_1-release-notes

 Description
 Firefox 4.0 does not work for the Administration Console Targeting dialogs. All other web pages display correctly. "Targeting dialogs" refer to those dialogs in which two adjacent columns of options are displayed, one for "Available Targets" and the other for "Selected Targets." A user can select the desired options and move them from one column to other. For example, such a dialog can be displayed by navigating to the Resources->JDBC->JDBC Resources->->Target page and then clicking Manage Targets. The resulting Manage Resource Targets page will not be displayed correctly in Firefox 4.0. Specifically, the CSS page formatting is not rendered, leaving just plain text and no layout. Workaround None. This is a rendering issue in Firefox 4.0. Other browsers and earlier versions of Firefox do not exhibit this behavior.

 Comments
 Comment by Scott Fordin [ 19/Apr/11 ] Added issue to 3.1 Release Notes. Comment by Anissa Lam [ 18/Jul/11 ] FF4 is EOL'ed and is not a supported browser. FF5 has replaced FF4, and we have tested Console works fine in FF5. Comment by Thorsten Gilfert [ 25/Jul/11 ] I get the same issue with FireFox 5 (Win Vista) too. See attached screenshot.

### [GLASSFISH-16159] asupgrade fails without internet connection Created: 04/Mar/11  Updated: 20/Dec/16  Resolved: 04/Mar/11

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

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

 Attachments: gf-16159.diff Tags: 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1-upgrade

 Description
 Without an internet connection, the upgrade tool fails while trying to parse the version out of the source domain.xml. The failure is here in UpgradeUtils.java: /* We don't need to validate the xml document now as that is the job of the upgrade code in the application server. We're only interested in the version information here, and if that is somehow wrong then the upgrade process will fail downstream as the document is parsed into serverbeans objects. */ public Document getDomainDocumentElement(String domainFileName) { DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true); Document resultDoc = null; try { DocumentBuilder builder = factory.newDocumentBuilder(); resultDoc = builder.parse(new File(domainFileName)); } catch (Exception ex) Unknown macro: { logger.log(Level.WARNING, stringManager.getString("upgrade.common.could_not_create_doc", new Object [] {domainFileName, ex.toString()})); } return resultDoc; } Example error: Could not create xml document object from file name /home/oracle/SUNWappserver/domains/domain1/config/domain.xml due to: java.net.UnknownHostException: www.sun.com The fix for this is simple – what's bad is that this code hasn't changed since the initial commit in the v3 workspace, and no one has reported it till now (though GLASSFISH-14951 came close). We should fix this for any 3.1.next release.

 Comments
 Comment by Bobby Bissett [ 04/Mar/11 ] The workaround is easy: 1. Copy source domain to the target domains directory (first rename the 3.1 domain if it has the same name as the one to be upgraded). 2. "asadmin start-domain --upgrade " Comment by Bobby Bissett [ 04/Mar/11 ] Patch, take 1. Comment by Bobby Bissett [ 04/Mar/11 ] This is fixed in revision 45411. Comment by Scott Fordin [ 15/Mar/11 ] Does this still need to be included in the 3.1 Release Notes? Comment by Bobby Bissett [ 15/Mar/11 ] Thanks for checking. I guess it probably should include that you can run into this when using the upgrade tool with a 2.x domain and no internet connection. Let me know if you want me to file a separate issue or something. Comment by Scott Fordin [ 15/Mar/11 ] Ah, I can see where this could start to get messy. Two questions: 1) Should this information be included in the Upgrade Guide proper rather than the Release Notes? For example, it go in the Correcting Potential Upgrade Problems section (http://download.oracle.com/docs/cd/E18930_01/html/821-2437/gkrfh.html) 2) More messy, does this issue not have implications for performing closed network upgrades, as described in http://download.oracle.com/docs/cd/E18930_01/html/821-2416/gjcya.html? I suppose I can just add the topic to Release Notes, but the closed network upgrade bit concerns me. Is there something I'm missing that makes this issue moot in closed network upgrade context? I mean, a user could copy the source domain to the target domain, as you state in the workaround, but would this workaround be necessary when the repositories are configured to be local? Comment by Snjezana Sevo-Zenzerovic [ 15/Mar/11 ] As far as I can tell we are OK when it comes to closed network upgrade section since there we tell user to run 'asadmin start-domain --upgrade' command which is not affected by this... This affects only the scenario where user has side-by-side installations and runs 'upgradetool' to upgrade domain config. So, closed network updates (and regular updates) which upgrade the domain config "in place" using asadmin flag should be fine. It doesn't matter if repositories are local or remote. Comment by Bobby Bissett [ 16/Mar/11 ] Thanks Snjezana – I didn't get to this yesterday. I agree that we're ok on the closed-network upgrade/update. In fact, we're fine on any update since this only affects the case of upgrading from a 2.X domain. Only 2.X domains have a schema in them, and the stupid stupid stupid code in the upgrade tool tries to check that schema when it parses the domain (and it's only parsing it in order to check a version, nothing else). So this only affects the internal version checking code in the tool, and doesn't apply to an actual upgrade at all. The "asadmin start-domain --upgrade" workaround is unaffected. To answer Scott's big question, this should probably be in the "correcting potential..." section, as it may be fairly common. (This isn't technically an upgrade problem, but that's irrelevant.) There could be a lot of people doing an upgrade from 2.X internally, and it would be good if they don't have to hunt for this info. Scott, let me know if there's something else you'd like me to do on this. I will be so happy if/when we drop the upgrade tool for 3.2. Comment by Scott Fordin [ 08/Apr/11 ] Added topic to 3.1 Upgrade Guide. Comment by Scott Fordin [ 13/Apr/11 ] Also added issue to 3.1 Release Notes.

### [GLASSFISH-16153] Admin GUI hangs on first access after installation on some Solaris Server Hardware. Created: 04/Mar/11  Updated: 20/Dec/16  Resolved: 04/Mar/11

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

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

 Attachments: prtfru Tags: 3_1-next, 3_1-release-note-added, 3_1-release-notes

 Description
 This has been logged twice internally by the support organization in different Geos after performing installations of GF 3.1 on Solaris servers (i.e. bigger than your under-the-desk workstation). Please refer to defects 7023434 and 7023307 for additional detail. The problem is that during the generation of the registration page, if the SolarisSystemEnvironment.getSNViaPrtfruX() method is called, then if the output from the prtfru -x command is significant (a good sized server could output over 3000 lines/150Kbytes) then the page generation will hang. The problem is the SystemEnvironment.getCommandOutput() implementation. This simply forks a process and waits for it to complete, without considering that the command might produce enough output to fill its standard out / standard error buffers, which would lead to the command being blocked until the buffers are drained: ProcessBuilder pb = new ProcessBuilder(command); p = pb.start(); p.waitFor(); This is not good. What the end user sees is the initial "Admin Console" loading screen, which is then replaced will a blank white screen and the browser hangs indefinitely. The only way to continue is to kill the prtfru command that is hung. The solution is already available in the code base, and would be to reuse the com.sun.enterprise.universal.process.ProcessStreamDrainer: ProcessBuilder pb = new ProcessBuilder(command); p = pb.start(); psd = ProcessStreamDrainer.save("RegEnvCommandProcess", p); return psd.getOutString();

 Comments
 Comment by Anissa Lam [ 04/Mar/11 ] sounds like we are generating the registration.jsf during console initialization, maybe we should move the code to till user press the 'GlassFish Registration' button in the common task page. Siraj, do we have workaround for this ? maybe a way to stop this generation from happening ? Comment by sirajg [ 04/Mar/11 ] A fix has been checked into the trunk, so that the registration html generation happens when the user presses the register button. There are three work arounds : Workaround 1 : kill the process running prtfru, for example: ptree cat /path/to/install-dir/glassfish/domains/your-domain-name/config/pid 20365 /usr/jdk/jdk1.6.0_23/bin/java -cp /path/to/install-dir/glassfish/modules/glass 20385 /usr/sbin/prtfru kill -9 20385 Workaround 2: Prior to logging into the DAS for the first time run: Make the directory /glassfish/lib/registration/ read-only - i.e. chmod -w /glassfish/lib/registration/ This will result in the registration file not being generated. Registration option will not be displayed. Workaround 3: Prior to logging into the DAS for the first time run: touch /glassfish/lib/registration/registration.html The downside to approach (2) and (3) is that registering the product is not possible. Comment by tecknobabble [ 04/Mar/11 ] Okay, you are deferring the generation of the registration page But are you changing the code that will still hang when you press the "Register" button? The crux of this is the SystemEnvironment.getCommandOutput() doesn't drain the command's output as it runs, and hence if the command produces enough output to fill its output buffers any further output will block waiting for the buffers to be read. Since the getCommandOutput() just does a p.waitFor() it will sit forever until someone goes and kills the forked process. Comment by tecknobabble [ 04/Mar/11 ] This is a shell script that can be used to simulate the problem seen on larger servers. Rename your existing /usr/sbin/prtfru and replace it with this copy. Make sure it has execute privileges on it. Comment by Scott Fordin [ 04/Mar/11 ] Added issue to 3.1 Release Notes. Comment by sirajg [ 04/Mar/11 ] A fix has also been checked in to ensure that the command output is drained. This was the underlying issue. So the fix consists of two parts : 1) Delay registration file generation till it is needed. 2) Drain command output in SystemEnvironment.getCommandOutput(). Comment by Anissa Lam [ 04/Mar/11 ] change fix version to 3.1_b01 since this is fixed in the trunk. add 3_1-next tag as requested by Chris.

### [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-16067] 3.1 GlassFish installer takes longer to bootstrap Update Center than in 3.0.1 Created: 21/Feb/11  Updated: 20/Dec/16  Resolved: 15/Jun/11

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

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

Issue Links:
 Dependency depends on UPDATECENTER2-2175 Bootstrapper performance regression f... In Progress
Status Whiteboard:

Flagging for release notes. There is no workaround (although not using a proxy server, if possible, can improve performance).

If the user wishes to confirm the download process is making progress they can look in "glassfish3/.org.opensolaris,pkg/download/<number>" and verify that the number of files is increasing over time.

Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_1-approved

 Description
 On my MacBook it takes the 3.1 installer about 4m30s to bootstrap the Update Center (go from 41% to 69%). With 3.0.1 it takes about 1m30s. This is likely caused by a performance regression in UC 2.3.3. See issue UPDATECENTER2-2175 This was with the Unix installer, B43 web profile.

 Comments
 Comment by Joe Di Pol [ 23/Feb/11 ] The times in the description where using a network proxy. When I removed the proxy the time improved to 3m30s – a bit of an improvement. Comment by Joe Di Pol [ 22/Mar/11 ] A fix that improves the performance has been checked into Update Center (see linked bug). We will integrate this for 3.2. Comment by Scott Fordin [ 12/Apr/11 ] Added issue to 3.1 Release Notes. Comment by Joe Di Pol [ 20/Apr/11 ] A fix for UPDATECENTER2-2175 was integrated in UC 2.3.4-B53. This will be picked up for GlassFish 3.1.1. That fix significantly speeds up downloaded performance over what is in UC 2.3.3/GF 3.1 (over twice as fast), but is still not as fast as UC 2.3.2/3.0.1 on most networks. Comment by Nazrul [ 21/Apr/11 ] We should integrate the current UC fix (UC issue 2175) in 3.1.1 Comment by Joe Di Pol [ 22/Apr/11 ] Assigning to Snjezana to pick up UC 2.3.4,0-53 in the GlassFish build. Comment by scatari [ 06/Jun/11 ] Pre-approving this fix for 3.1.1. Comment by Snjezana Sevo-Zenzerovic [ 15/Jun/11 ] Fixed in 3.1.1 b08 and the trunk since updated pkg-client.jar has been integrated.

### [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-16061] could not find Factory: javax.faces.context.FacesContextFactory Created: 21/Feb/11  Updated: 19/Dec/16  Resolved: 11/May/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1_dev
Fix Version/s: None

 Type: Bug Priority: Major Reporter: bleathem Assignee: rogerk Resolution: Won't Fix Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Linux, Seam 3

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

 Description
 On running my JSF/Seam 3 application (using netbeans), the application startup fails with the message: WARNING: StandardWrapperValve[FacesServlet]: PWC1382: Allocate exception for servlet FacesServlet java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory I have to undeploy my application, restart glassfish, and re-deploy my application (sometimes several times) to get this problem to go away. This problem is intermittent. -------------- Stack trace: WARNING: StandardWrapperValve[FacesServlet]: PWC1382: Allocate exception for servlet FacesServlet java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:815) at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:317) at javax.faces.webapp.FacesServlet.init(FacesServlet.java:253) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1439) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1071) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:189) 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)  Comments  Comment by rogerk [ 21/Feb/11 ] Can you provide a war for this app? Comment by bleathem [ 21/Feb/11 ] I'll see if I can put together a simplified war that exhibits this behaviour. Comment by rogerk [ 21/Feb/11 ] Simplified app would be nice. I know that there are probably a lot of libraries with a Seam3 aopp. Comment by rogerk [ 21/Feb/11 ] Simplified app would be nice. I know that there are probably a lot of libraries with a Seam3 aopp. Comment by rogerk [ 21/Feb/11 ] Tagging until more information is available. Comment by bleathem [ 22/Mar/11 ] I can now reproduce this behaviour, and I have a workaround, with a small caveat. I cannot run my app with the weld-osgi-bundle.jar provided with glassfish, so I replace it with the latest weld-osgi-bundle snapshot. The error comes up consistently in my sample app, and I can make it consistently going away by adding the following to my web.xml: Faces Servlet javax.faces.webapp.FacesServlet 1 I can provide you with the sample app if this information is not enough to go on. Comment by rogerk [ 23/Mar/11 ] Are you saying your app was not configured to go through the FacesServlet? Comment by Scott Fordin [ 23/Mar/11 ] Need more info to add issue to 3.1 Release Notes. Comment by rogerk [ 11/May/11 ] Closing as I have not heard back from reporter and this appears to be a configuration issue - in addition the reporter has workaround for config issue. Comment by bleathem [ 16/May/11 ] This issue is sporadic issue, and is observed when a JSF application does not register the Faces Servlet in the web.xml. com.sun.faces.config.FacesInitializer will attempt to initialize the JSF Servlet, which normally works fine, except when Seam Faces is included in the application, which also tries to initialize the Servlet. This bug is not deterministic due to the random ordering of listeners by Glassfish. For more information, please see the corresponding issue in SeamFaces: https://issues.jboss.org/browse/SEAMFACES-163 Comment by Scott Fordin [ 17/May/11 ] Added issue to 3.1 Known Issues section of the 3.1-3.1.1 Release Notes. ### [GLASSFISH-16048] Application info page: status not show correctly and virtual servers changes not saved. Created: 18/Feb/11 Updated: 20/Dec/16 Resolved: 18/Feb/11 Status: Closed Project: glassfish Component/s: admin_gui Affects Version/s: 3.1_dev Fix Version/s: 3.1.1_dev  Type: Bug Priority: Major Reporter: Anissa Lam Assignee: Anissa Lam Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Issue Links:  Duplicate is duplicated by GLASSFISH-16054 Regression: Status showed incorrectly... Resolved Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes  Description  I just notice 2 issues in application information page after application is deployed. This only occurs in DAS ONLY environment. The status checkbox is always unchecked regardless whether the application is enabled or disabled. The display is wrong. Changing the list of virtual servers is not persisted. The display for the status was not correct is a regression i introduced when fixing GLASSFISH-15848. Not able to save the virtual servers is due to the capitalization of the attribute variable. I believe the issue has been there for a while.  Comments  Comment by Anissa Lam [ 18/Feb/11 ] The issue has been fixed in the trunk, Sending appEdit.layout Transmitting file data . Committed revision 45179. ================== We want to release note this to provide a workaround for user. User will only see this issue when there is NO clusters or standalone instances created in the domain. For the status of the application, always look at the applications table that lists out the applications. The status is correctly displayed there, and user can use this table to change the status as well. To change the virtual server for the deployed application, use the CLI set command. use the following CLI to see the info: %asadmin get server.application-ref..* and set command to change the list of virtual servers for this application. %asadmin set server.application-ref..virtual-servers= example of get : %asadmin get server.application-ref.hello examples of set: %asadmin set server.application-ref.hello.virtual-servers=server,myVS or %asadmin set server.application-ref.hello.virtual-servers=myVS Comment by Anissa Lam [ 18/Feb/11 ] Fixed in the trunk. Comment by Scott Fordin [ 12/Apr/11 ] Added issue to 3.1 Release Notes. Comment by shaline [ 22/Jun/11 ] Verified on promoted b08. ### [GLASSFISH-16044] appclient in cygwin passing extra empty string Created: 17/Feb/11 Updated: 20/Dec/16 Resolved: 30/Mar/11 Status: Resolved Project: glassfish Component/s: standalone_client Affects Version/s: 3.1_dev Fix Version/s: 3.1.1_dev  Type: Bug Priority: Major Reporter: Sreekanth Assignee: Tim Quinn Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Windows, Cygwin  Attachments: AppClientTest.ear AppClientTestClient.jar Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1windows  Description  When running appclient on a windows machine with cygwin, the appclient is passing an extra empty String to the program arguments. But when running on command line in windows doesnt show that problem. See below: Linux run: =========== sreekanth@spidy:~/NetBeansProjects/AppClientTest$ asadmin deploy --retrieve dist --force=true dist/AppClientTest.ear Authentication failed with password from login store: /home/sreekanth/.asadminpass Enter admin password for user "admin"> Application deployed with name AppClientTest. Command deploy executed successfully. sreekanth@spidy:~/NetBeansProjects/AppClientTest$appclient -client dist/AppClientTestClient.jar Arguments length is :0 sreekanth@spidy:~/NetBeansProjects/AppClientTest$ Window Run: =========== aroot@bigapp-x2250-1 /cygdrive/c/ha/tmp-sree $/cygdrive/c/ha/glassfish3/glassfish/bin/asadmin deploy --retrieve . --force=true AppClientTest.ear Application deployed with name AppClientTest. Command deploy executed successfully. aroot@bigapp-x2250-1 /cygdrive/c/ha/tmp-sree$ /cygdrive/c/ha/glassfish3/glassfish/bin/appclient -client AppClientTestClient.jar Arguments length is :1

 Comments
 Comment by Tim Quinn [ 18/Feb/11 ] Sreekanth, Please contact me directly via e-mail so I can arrange to investigate this on your system. Thanks. Comment by Tim Quinn [ 20/Feb/11 ] I have reproduced this issue on a Windows system with cygwin installed. Investigating. Comment by Tim Quinn [ 21/Feb/11 ] We are excluding this from 3.1. It seems to be due to an interaction between the way the CLIBootstrap class generates the java command for launching the app client and how the cygwin shell parses the command into arguments. There is currently a trailing blank in the generated command line. This is not an issue in other environments, but cygwin in this case seems to treat the blank as a separator in front of an empty argument. Users who have app clients that process a variable number of arguments and run those clients on Windows using cygwin should be aware of this issue. One workaround would be to make sure the client deals correctly with an empty argument. Comment by Tim Quinn [ 14/Mar/11 ] Release notes info: Summary: Using cygwin on Windows, the app client container (ACC) passes an extra empty-string argument to the client's main method. This might result in the app client throwing an index-out-of-range exception if the client does not guard itself against empty argument values. Workarounds (reiterating from the Feb. 21. comment): 1. If your client works with a variable number of arguments make sure that it protects itself against empty argument values. 2. Avoid using cygwin on Windows for clients that cannot be made to guard against an empty argument value. Comment by Tim Quinn [ 17/Mar/11 ] Fix checked in: Project: glassfish Repository: svn Revision: 45605 Author: tjquinn Date: 2011-03-17 18:03:10 UTC Link: Log Message: ------------ Fix for 16044 Under cygwin on Windows, a trailing blank on the generated java command line was parsed as an empty additional command-line argument and passed as such to the client. This change causes the generated java command to no longer contain an extra trailing blank. Tests: QL, deployment devtests, cygwin on Windows test Revisions: ---------- 45605 Modified Paths: --------------- trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java Comment by Tim Quinn [ 24/Mar/11 ] The earlier fix causes problems when the user enters JVM options on the appclient command line. There is a missing space between the user-provided JVM options and some JVM options which CLIBootstrap adds to the generated java command line. Comment by Scott Fordin [ 24/Mar/11 ] Added topic to 3.1 Release Notes. Added "release note added" tag. Comment by Tim Quinn [ 30/Mar/11 ] Fix checked in. Project: glassfish Repository: svn Revision: 45773 Author: tjquinn Date: 2011-03-30 15:57:40 UTC Link: Log Message: ------------ Additional refinement for fix to 16044 This change resolves a problem in which user-specified JVM options were not separated from other options by a space. It also cleans up the earlier fix logic a bit and adds some javadoc for some methods. Tests: QL, deployment devtests, cygwin on Windows test Revisions: ---------- 45773 Modified Paths: --------------- trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java

### [GLASSFISH-16040] ReleaseNotes: document Restar Required issues Created: 17/Feb/11  Updated: 19/Dec/16  Resolved: 18/Mar/11

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

 Type: Bug Priority: Major Reporter: lidiam Assignee: Scott Fordin 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
 This is an umbrella bug for documenting numerous issues with Restart Required. Please find the details in the following query: http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10358 Each bug in the query should be documented in Release Notes for 3.1.

 Comments
 Comment by Scott Fordin [ 03/Mar/11 ] Added issue to 3.1 Release Notes. Comment by Anissa Lam [ 14/Mar/11 ] I am re-opening this issue so that the next doc refresh can have the correct summary. Currently, it says: "Description There are a number of functions in that you can perform through the GlassFish Server Administration Console. These functions require a server restart, but the Administration Console does not correctly convey this." This is not quite correct. It is saying that the Admin Console does not show the correct information to user, when in fact, the information that console shown is correct. It is that the backend or each of the components in the bug list doesn't specify that restart is required. In order word, even if user is using CLI to look at the status, eg. list-domains or list-instances to check if instance need restart, they will see the wrong information. So, i think the wording should be changed to reflect the issue more accurately. Comment by Scott Fordin [ 18/Mar/11 ] Reworded issue description. Added ulinks to umbrella issues. Comment by Scott Fordin [ 24/Mar/11 ] Added "release note added" tag. Comment by lidiam [ 08/Jul/11 ] Verified in Release Notes for 3.1 release.

### [GLASSFISH-16037] create-jvm-options subcommand options incorrectly parsed by asadmin Created: 17/Feb/11  Updated: 20/Dec/16  Resolved: 18/Feb/11

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

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

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

 Description
 The asadmin utility is incorrectly interpreting options of the create-jvm-options subcommand as asadmin utility options. As a result, an attempt to create an option, for example -Xrs, fails: asadmin> create-jvm-options -Xrs Non-boolean option: X, not allowed in argument: -Xrs Usage: asadmin [-H|--host ] [-p|--port ] [-u|--user ] [-W|--passwordfile ] [t|-terse[=]] [s|-secure[=]] [e|-echo[=]] [I|-interactive[=]] [?|-help[=]] create-jvm-options [command-specific options] Command create-jvm-options failed. The usage message appears to be in the style of a v2 usage message. In GlasFish 3, asadmin utility options are not provided in the usage message. To workaround this problem, run the create-jvm-options command in single mode specifying at least one asadmin utility option, for example: dashost$asadmin --host dashost create-jvm-options -Xrs Created 1 option(s) Command create-jvm-options executed successfully.  Comments  Comment by Bill Shannon [ 18/Feb/11 ] Missed one case in the special cases for commands that treat unknown options as operands. Also, some asadmin hidden commands had short option names, which was further confusing things. I'm removing the short names for the hidden options. Comment by Scott Fordin [ 24/Mar/11 ] Added topic to 3.1 Release Notes. Added "release note added" tag. ### [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-15987] Display Restart Required when a system-property which is referenced by a jvm-option is changed Created: 15/Feb/11 Updated: 20/Dec/16 Resolved: 17/Mar/11 Status: Resolved Project: glassfish Component/s: admin Affects Version/s: 3.1_dev Fix Version/s: 3.1.1_dev  Type: Bug Priority: Major Reporter: Jennifer Chou Assignee: Tom Mueller Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified  Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes  Description  Restart Required should also appear in Admin Console and 'asadmin list-domains' when a change is made to the system-property which is referenced by a jvm-option. In the code we need to check if the system property is changed and referenced by a jvm-options and show the Restart Required. For example in server-config: 1) Create a system property 2) Change jvm option to use system property -Xmx$ {JVM_HEAP_SIZE} 3) Restart GlassFish 4) Change system property value for JVM_HEAP_SIZE 5) Upper left of Admin Console does not show Restart Required asadmin list-domains does not show 'requires restart' Checked on v2.1.1, that changing a system-property referenced by a jvm-option, show restart required in asadmin list-domains (The Admin Console doesn't display): C:\glassfish-v2.1.1-b31g\glassfish\bin>asadmin list-domains domain1 requires restart Command list-domains executed successfully.

 Comments
 Comment by Jennifer Chou [ 15/Feb/11 ] I checked in v2.1.1 that even a change to a system property that's not referenced by anything else, will trigger a restart required to be displayed. C:\glassfish-v2.1.1-b31g\glassfish\bin>asadmin list-domains domain1 requires restart Command list-domains executed successfully. So in the code, we can just check whether a system property is changed and trigger a restart required state. Comment by Chris Kasso [ 16/Feb/11 ] We have a collection of "Restart Required" issues that remain unresolved in 3.1. This likely warrants an umbrella Release Note item which addresses the more general problems we are seeing in this area. Here's a query that identifies many of the existing "Restart Required" issues: http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10358 Comment by Tom Mueller [ 01/Mar/11 ] The root cause of this problem is that when a system property change is made, the GenericJavaConfigListener class does not take into account that some JVM options, such as -Xmx, might be depending on the value of a system property, so the system property change event is not returned from GenericJavaConfigListener as an UnprocessedChangeEvent, so the UnprocessedConfigListener doesn't pick it up to set the restart required flag. The processing of the JVM options, including resolution of property values, occurs within the launcher, which is executed by asadmin, not the server (specifically in the GFLauncher class when it calls TokenResolver). There is no record kept of what tokens were resolved, or where they came from. Considering this a bit deeper, the token resolution that occurs for JVM options uses as its sources the following: 1. the shell environment, e.g., "export a=b" 2. values in the asenv.conf or asenv.bat file 3. values passed via -Da=b as specified in the asadmin script 4. system-properties in the domain.xml (server, config, and domain) 5. JVM options (-Da=b in the jvm-options in the domain.xml) 6. profiler properties (from the domain.xml) If any of these change such that the JVM options would be recalculated for the instance, then a restart-required should be triggered. For example, if the asenv.conf file or asadmin file is edited, or the user changes their environment. The server cannot detect changes in the latter, but it could be looking at those files. This bug is only about changes to system-properties in the domain.xml, but it does raise the question of what else should be checked too. The suggested fix for this bug is to modify the GenericJavaConfigListener class so that it looks at the token that are referenced by the JVM options, and if the value of a token changes, then the change should be returned as an UnprocessedChangeEvent. This will require making GenericJavaConfigListener listen for system property change notifications. Comment by Scott Fordin [ 07/Mar/11 ] Added issue to 3.1 Release Notes as part of "Restart Required" umbrella issue. Comment by Tom Mueller [ 08/Mar/11 ] This isn't actually fixed yet. Comment by Tom Mueller [ 17/Mar/11 ] Fixed in revision 45608 on the trunk. If a system-property is referenced by a JVM option, any change to that any system property with that name will cause a restart-required, even if the actual value did not change. For example, consider this: -Dabc=${foo} If you then do: asadmin create-system-property --target domain foo=xyz This will trigger the restart-required flag, even though the value is really overriding the value for foo, so when the server restarts, the value of the abc property won't change. If this really bothers you, please file another issue. However, the fix that is checked in fixes the problem from the initial description. Comment by Scott Fordin [ 18/Mar/11 ] Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes. Comment by Scott Fordin [ 24/Mar/11 ] Added "3_1-release-note-added" tag. ### [GLASSFISH-15986] Column APPLICATIONID is missing from bundled sql scripts for ejb timer table creation. Created: 15/Feb/11 Updated: 20/Dec/16 Resolved: 04/Mar/11 Status: Resolved Project: glassfish Component/s: ejb_container Affects Version/s: 3.1_dev Fix Version/s: 3.1.1_dev  Type: Bug Priority: Major Reporter: sonymanuel Assignee: marina vatkina Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified  Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes  Description  In 3.1, the bundled timer table creation sql scripts are missing column APPLICATIONID. sony@nila:/home2/sony/builds/glassfish3/glassfish/lib/install/databases$ cat ejbtimer_derby.sql CREATE TABLE EJB_TIMER_TBL ( CREATIONTIMERAW BIGINT NOT NULL, BLOB BLOB(2G), TIMERID VARCHAR(255) NOT NULL, CONTAINERID BIGINT NOT NULL, OWNERID VARCHAR(255), STATE INTEGER NOT NULL, PKHASHCODE INTEGER NOT NULL, INTERVALDURATION BIGINT NOT NULL, INITIALEXPIRATIONRAW BIGINT NOT NULL, LASTEXPIRATIONRAW BIGINT NOT NULL, SCHEDULE VARCHAR(255), CONSTRAINT PK_EJB_TIMER_TBL PRIMARY KEY (TIMERID) ) ;

 Comments
 Comment by marina vatkina [ 15/Feb/11 ] I'm not sure how this could happen, but all but one .sql files are missing this column. The sql files are for the user as a ref point, or to be able to create the table themselves. By default EJB Timer service creates the table on the 1st deploy. Fixing the files won't affect the execution. Comment by marina vatkina [ 15/Feb/11 ] Fixed on trunk with rev 45149 Comment by Scott Fordin [ 04/Mar/11 ] Need more information to add to notes. Comment by Scott Fordin [ 04/Mar/11 ] Added issue to 3.1 Release Notes. Comment by Scott Fordin [ 24/Mar/11 ] Added "3_1-release-note-added" tag.

### [GLASSFISH-15985] NullPointerException when accessing OSGi web application Created: 15/Feb/11  Updated: 20/Dec/16  Resolved: 04/Nov/11

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

 Type: Bug Priority: Major Reporter: chaoslayer Assignee: Ed Burns Resolution: Fixed Votes: 4 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified

 Attachments: dummy-web.war     message.txt     server-3.1-b36.log     server-3.1-b37.log Status Whiteboard: jsf_2_1_1 Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description

### [GLASSFISH-15775] Remote EJBs fail with ClassCastException in embeddable Glassfish Created: 31/Jan/11  Updated: 20/Dec/16  Resolved: 30/May/11

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

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

 Attachments: glassfish-test-arquillian.zip Tags: 3_1-exclude, 3_1-fishcat, 3_1-release-note-added, 3_1-release-notes, 3_1_1-approved, 3_1_1-next

 Description
 I think I've found a specification violation in the embeddable Glassfish project. My apologies if it turns out that this is not the case, but I've taken the liberty of setting the priority to Major because I don't see any wiggling out of this one. Here's what the specification has to say about business interfaces of stateless session beans in section 4.9.7: "If the business interface is a remote business interface, the argument and return values must be of valid types for RMI/IIOP. The remote business interface is not required or expected to be a java.rmi.Remote interface." My business interface is declared thusly: public interface AppealTypeManager extends DAO { public Collection findAllAppealTypes(final PagingControl pagingControl); } (Note the lack of @Remote, and the lack of "extends Remote".) My bean class is declared thusly: @Stateless//(name = "AppealTypeManager") @TransactionAttribute(TransactionAttributeType.REQUIRED) @Remote(AppealTypeManager.class) public class AppealTypeManagerBean extends AbstractDAO implements AppealTypeManager { // ...etc. } I look up a reference to the remote business interface like this: final Context c = new InitialContext(); final AppealTypeManager a = (AppealTypeManager)c.lookup("java:global/test-classes/AppealTypeManagerBean"); When I deploy my EJB module to embeddable Glassfish, I get the following error upon lookup: javax.naming.NamingException: Lookup failed for 'java:global/test-classes/AppealTypeManagerBean' in SerialContext[myEnv= {java.naming.factory.initial=com.sun.enterprise.naming.impl.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: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException]] at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:525) at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455) at javax.naming.InitialContext.lookup(InitialContext.java:392) at javax.naming.InitialContext.lookup(InitialContext.java:392) at com.jenzabar.junit.ejb.dbunit.mem.GlassfishEmbeddedStrategy.getBean(GlassfishEmbeddedStrategy.java:126) at com.jenzabar.junit.ejb.dbunit.mem.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:98) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:145) at org.apache.maven.surefire.Surefire.run(Surefire.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017) Caused by: javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException] at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:434) at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:559) at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:521) ... 34 more Caused by: java.lang.ClassCastException at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:262) at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137) at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$12.read(DynamicMethodMarshallerImpl.java:353) at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483) at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203) at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152) at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227) at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java) 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.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:422) ... 38 more Caused by: java.lang.ClassCastException: Object is not of remote type java.rmi.Remote at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:254) ... 50 more Again, the specification does not require a remote business interface to extend java.rmi.Remote, but it would appear that the Glassfish embedded runtime thinks it's necessary.

 Comments
 Comment by Bhavanishankar [ 31/Jan/11 ] This seems to be an EJB container (or may be naming) issue. Hence re-categorizing. It can also be easily reproducible by running v2/appserv-tests/devtests/ejb/ejb31/embedded/remote Comment by ljnelson [ 01/Feb/11 ] This bug is present back through build 33; prior to that the API changed. (Of course it looks from the signature of the devtest you're talking about that this goes back to Glassfish 2?) "Forum" discussion here: http://www.java.net/forum/topic/glassfish/glassfish/glassfish-embedded-specification-violati Comment by ljnelson [ 01/Feb/11 ] This bug seems to have something to do with http://java.net/jira/browse/EMBEDDED_GLASSFISH-119, or rather both of them probably have the same underlying problem. It is my understanding that javax.ejb.embeddable.EJBContainer is under no obligation to support @Remote EJBs, and that org.glassfish.embeddable.* MUST (or at least is intended to) support @Remote EJBs. Comment by marina vatkina [ 01/Feb/11 ] Bhavani, please take a look: changes for rev 38343 & 38344 caused this regression. If you think that EJB container needs to adjust for these changes, it'd be helpful to know what it should be aware of. I do not see anything suspicious about the CLs used in the EJBUtils.lookupRemote30BusinessObject. Comment by Bhavanishankar [ 03/Feb/11 ] Marina, the change revs you are referring to seem like the changes related to OSGi. IMO that can not be the cause for this. Why do you think otherwise? Comment by marina vatkina [ 03/Feb/11 ] Bhavani, ejb31/embedded/remote passes with rev 38342 and fails with the ClassCastException: Object is not of remote type java.rmi.Remote with rev 38344. Comment by Nazrul [ 07/Feb/11 ] Since this did not make it into RC2, excluding from 3.1 count. Comment by Sanjeeb Sahoo [ 07/Feb/11 ] This is a Thread context class loader issue. GlassFish.start() sets the context class loader to an internal class loader and forgets to reset it after the call is complete. This is why user's classes can no longer be loaded using the context class loader in the thread that starts the server. Bhavani & I have discussed this and it will be addressed soon. "A possible work around is to set the context class loader before looking up the remote EJB." e.g., GlassFish gf = GlassFishRuntime.bootstrap().newGlassFish(); gf.start(); gf.getDeployer().deploy(myapp); ClassLoader oldCl = Thread.currentThread().getContextClassLoader(); try { Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); new InitialContext().lookup(myEJB); } finally { Thread.currentThread().setContextClassLoader(oldCl); } Comment by Bhavanishankar [ 07/Feb/11 ] Just added a devtest under v3/tests/embedded/ejb/remoteejb which follows the workaround. Comment by Scott Fordin [ 23/Mar/11 ] Need more info to add issue to 3.1 Release Notes. Comment by Scott Fordin [ 13/Apr/11 ] Does this still need to be included in the 3.1 Release Notes? If so, I need more information. Comment by Scott Fordin [ 17/May/11 ] Went with what information I had. Added issue to 3.1 Known Issues section of 3.1-3.1.1 Release Notes. Comment by Bhavanishankar [ 27/May/11 ] Why fix this issue in 3.1.1? > This is issue that is directly reported by community. Which is the targeted build of 3.1.1 for this fix? > b07 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? > Regular QA tests should be run. No new test is required. Embedded devtest will take care of verifying the fix. Comment by Bhavanishankar [ 30/May/11 ] Adding 3.2 also as the fixVersion Comment by vasilievip [ 05/Aug/11 ] Bug still exists on GF 3.1.1, please reopen. Please find attached testcase. Comment by jyrkip [ 27/Sep/13 ] Happens on embedded 4.0 too.

### [GLASSFISH-15763] [UB][regression] jpaRLCreateEMF failure on sybase Created: 31/Jan/11  Updated: 02/Dec/11  Resolved: 13/Apr/11

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

 Type: Bug Priority: Major Reporter: sherryshen Assignee: Scott Fordin Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Solaris and Linux

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

 Description
 jpaRLCreateEMF failure on sybase glassfisg-3.1-b39.zip StandardWrapperValve[JpaServlet]: PWC1406: Servlet.service() for servlet JpaServlet threw exception javax.persistence.PersistenceException: Exception [EclipseLink-7197] (Eclipse Persistence Services - 2.2.0.v20110114-r8831): org.eclipse.persistence.exceptions.ValidationException Exception Description: Null or zero primary key encountered in unit of work clone [[JpaBean id=0, name=JpaBean]], primary key [0]. Set descriptors IdValidation or the "eclipselink.id-validation" property. at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:747) The test passed on derby with v3.1 b39. The test passed on sybassdd with b3.0 b64.

 Comments
Comment by sherryshen [ 31/Jan/11 ]

To reproduce the failure:
set env with referece of
http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=V31CoreInstruction
where db info is in workspace
appserver-sqe/build-config/sybase_datadirect.properties
To run test,
cvs co appserver-sqe/bootstrap.xml
cd $SPS_HOME ant -f bootstrap.xml co-ejb ant start-domain ant sybase-setup cd pe/ejb/ejb30/war/jpaRLCreateEMF ant sybasedd all The clinet output shows: [java] WS HOME appserver-sqe [java] url=http://localhost:8080/RLCreateEMF/index.jsp [java] url=http://localhost:8080/RLCreateEMF/jpa [java] Unexpected return code: 500 ..... [java] ----------------------------------------- [java] - EJB3-RLCreateEMF-WAR-J2DB:jsp: PASS - [java] - EJB3-RLCreateEMF-WAR-J2DB:servlet: FAIL - server.log with FINE EL is saved in http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build39/dbtest/server.log.fine.jpaRLCreateEMF which gives sybase info. [#|2011-01-31T10:25:54.468-0800|INFO|glassfish3.1| javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=104;_ThreadName=Thread-1;| [EL Config]: 2011-01-31 10:25:54.467-ServerSession(32895865)-Connection(22292204) --Thread(Thread[http-thread-pool-8080(4),5,grizzly-kernel]) --Connected: jdbc:datadirect:sybase://jsepc11.east.sun.com:5000;CATALOGOPTIONS=2;CONNECTIONRETRYDELAY=1;BULKLOADBATCHSIZE=1000;DATABASENAME=;MAXPOOLEDSTATEMENTS=0;PROGRAMID=0000016a;TRUSTSTOREPASSWORD=;VALIDATESERVERCERTIFICATE=true;CODEPAGEOVERRIDE=;CONNECTIONRETRYCOUNT=5;ENABLEBULKLOAD=false;BATCHPERFORMANCEWORKAROUND=false;INITIALIZATIONSTRING=;FAILOVERPRECONNECT=false;WORKSTATIONID=;RESULTSETMETADATAOPTIONS=0;CLIENTUSER=;QUERYTIMEOUT=0;FAILOVERGRANULARITY=nonAtomic;HOSTNAMEINCERTIFICATE=;APPLICATIONNAME=;JAVADOUBLETOSTRING=false;LOADLIBRARYPATH=;IMPORTSTATEMENTPOOL=;ALTERNATESERVERS=;ERRORBEHAVIOR=Exception;ENCRYPTIONMETHOD=NoEncryption;ACCOUNTINGINFO=;CONVERTNULL=1;TRUSTSTORE=;JDBCBEHAVIOR=1;FAILOVERMODE=connect;AUTHENTICATIONMETHOD=UserIdPassword;LOGINTIMEOUT=0;LONGDATACACHESIZE=2048;LOADBALANCING=false;PREPAREMETHOD=storedProcIfParam;TRANSACTIONMODE=explicit;USEALTERNATEPRODUCTINFO=false;WORKAROUNDS=0;INSENSITIVERESULTSETBUFFERSIZE=2048;PACKETSIZE=0;CLIENTHOSTNAME=;SERVICEPRINCIPALNAME=;SELECTMETHOD=direct User: dbo Database: SQL Server Version: Adaptive Server Enterprise/15.5/EBF 17218 SMP/P/NT (IX86)/Windows 2003/ase155/2391/32-bit/OPT/Mon Nov 09 14:18:14 2009 Driver: Sybase Version: 4.2.0.017715 (F044224.U015808)  #] Comment by sherryshen [ 01/Feb/11 ] I used dd driver from sqe v3.0 fcs branch. I adjusted sqe trunk db properties according to sqe branch http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build39/dbtest/sybase_datadirect.properties.diff ! db.driver=com.sun.sql.jdbc.sybase.SybaseDriver ! db.class=com.sun.sql.jdbcx.sybase.SybaseDataSource ! db.xaclass=com.sun.sql.jdbcx.sybase.SybaseDataSource ! db.url=jdbc:sun:sybase://$

{db.host}

:${db.port} ;SID=$

{db.sid}

;PrepareMethod=direct

Then, I ran tests with sqe trunk and v3.1 build 39, and tests passed.
server.log gives driver version.
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build39/dbtest/server.log.sybasedd.v30driver
[#|2011-02-01T10:32:20.730-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|
_ThreadID=99;_ThreadName=Thread-1;|[EL Config]: 2011-02-01 10:32:20.73-ServerSession(3243394)Connection(31389825)-Thread(Thread[http-thread-pool-8080(1),5,
grizzly-kernel])--Connected: jdbc:sun:sybase://jsepc11.east.sun.com:5000;CATALOGOPTIONS=2;CONNECTIONRETRYDELAY=1;BULKLOADBATCHSIZE=1000;DATABASENAME=;MAXPOOLEDSTATEMENTS=0;PROGRAMID=0000016a;TRUSTSTOREPASSWORD=;VALIDATESERVERCERTIFICATE=true;CODEPAGEOVERRIDE=;CONNECTIONRETRYCOUNT=5;ENABLEBULKLOAD=false;INITIALIZATIONSTRING=;FAILOVERPRECONNECT=false;WORKSTATIONID=;RESULTSETMETADATAOPTIONS=0;CLIENTUSER=;QUERYTIMEOUT=0;FAILOVERGRANULARITY=nonAtomic;HOSTNAMEINCERTIFICATE=;CATALOGINCLUDESSYNONYMS=true;APPLICATIONNAME=;JAVADOUBLETOSTRING=false;LOADLIBRARYPATH=;IMPORTSTATEMENTPOOL=;ALTERNATESERVERS=;ERRORBEHAVIOR=Exception;ENCRYPTIONMETHOD=NoEncryption;ACCOUNTINGINFO=;CONVERTNULL=1;TRUSTSTORE=;JDBCBEHAVIOR=1;FAILOVERMODE=connect;AUTHENTICATIONMETHOD=UserIdPassword;LOGINTIMEOUT=0;LONGDATACACHESIZE=2048;PREPAREMETHOD=direct;LOADBALANCING=false;TRANSACTIONMODE=explicit;USEALTERNATEPRODUCTINFO=false;SID=cts5;WORKAROUNDS=0;INSENSITIVERESULTSETBUFFERSIZE=2048;PACKETSIZE=0;CLIENTHOSTNAME=;SERVICEPRINCIPALNAME=;SELECT METHOD=direct
User: dbo
Database: Adaptive Server Enterprise Version: Adaptive Server Enterprise/15.5/EBF
17218 SMP/P/NT (IX86)/Windows 2003/ase155/2391/32-bit/OPT/Mon Nov 09 14:18:14 2009
Driver: Sybase Version: 4.0.016204 (040313.014801)

Comment by sherryshen [ 01/Feb/11 ]

Mitesh and I recalled that this is an old doc issue.
http://java.net/jira/browse/GLASSFISH-2431

Tests passed with new driver 4.2 and v3.1 b39 after
adjusting db properties.
RCS file: /m/jws/appserver-sqe/build-config/sybase_datadirect.properties,v

! db.url=jdbc:datadirect:sybase://${db.host}:${db.port}
— 9,15 ----
! db.url=jdbc:datadirect:sybase://${db.host} :$

{db.port}

;PrepareMethod=direct

Comment by sherryshen [ 01/Feb/11 ]

Transfer this bug to docs.
Please verify if it is in RN.

Enclosed is the note from Mitesh
for reference.

When using Data direct driver with Basely, if you are trying to insert
an entity that uses GenerationType.IDENTITY, it will fail. This is
because Datadirect driver creates a stored procedure for every
parameterized prepared statement. Please set property
PrepareMethod=direct on the corresponding datasource to change this
behavior and workaround this issue.

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1 Release Notes.

### [GLASSFISH-15724] Glassfish Installer does not update MQ config file (imqenv.conf) with values Created: 27/Jan/11  Updated: 20/Dec/16  Resolved: 03/Mar/11

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

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

 Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, glassfish-3-1, install, messagequeue

 Description
 Glassfish Installer does not update MQ config file (imqenv.conf) with values (for example, JDK HOME dir). This would be useful when MQ is run independent of glassfish. I think the earlier versions of glassfish installers updated this file with Jdk home and other values. Appropriate workaround would be to update the imqenv.conf file (located under MQ_HOME/etc directory) manually.

 Comments
 Comment by scatari [ 27/Jan/11 ] 3.x installers haven't done this configuration required for MQ. Anyway this is too late to fix in 3.1, if its a requirement then we will address this in 3.2. Comment by scatari [ 27/Jan/11 ] Not sure if this is a possible release note candidate. If the MQ team feels that way, please do bring to "docs" team's attention. Comment by mathim [ 03/Mar/11 ] provide more info to doc team Comment by Jill Sato [ 03/Mar/11 ] Optionally for release notes (nice to have): ------------------------------------------ MQ executables will use the 'java' in the user's PATH. The user can also specify another Java Runtime by setting IMQ_DEFAULT_JAVAHOME in the imqenv.conf file. On Unix (e.g.) IMQ_DEFAULT_JAVAHOME=/usr/jdk/jdk1.6.0 On Windows (e.g.) IMQ_DEFAULT_JAVAHOME=c:\path\to\jdk Comment by Scott Fordin [ 03/Mar/11 ] Issue added to 3.1 Release Notes. Comment by Scott Fordin [ 24/Mar/11 ] Added "3_1-release-note-added" tag.

### [GLASSFISH-15721] "injection points in one bean deployment archive cannot be satisfied by a bean in a separate bean archive, even when they are from libraries in the same module (web archive)" Created: 27/Jan/11  Updated: 20/Dec/16  Resolved: 09/Jun/11

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

 Type: Bug Priority: Critical Reporter: stuartdouglas Assignee: Sivakumar Thyagarajan Resolution: Fixed Votes: 20 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified

Attachments: weld-osgi-bundle.jar
Issue Links:
 Duplicate duplicates GLASSFISH-15906 CDI resolver issues Resolved is duplicated by GLASSFISH-15888 CDI not working well on Glassfish v3.... Resolved is duplicated by GLASSFISH-15794 JAX-RS injection broken for library @... Resolved
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1_1-review

 Description
 The Bean Deployment Archive visibility graph does not correctly implement the spec. Beans in WEB-INF/lib are made availible to beans in WEB-INF/classes, however the converse is not true (i.e. beans is WEB-INF/classes cannot be injected into WEB-INF/lib injection points), and beans in one jar in WEB-INF/lib cannot be injected into beans in a different jar in WEB-INF/lib. According to the CDI and EE6 Platform spec both of these should work. https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/web/weld-integration/src/main/java/org/glassfish/weld/DeploymentImpl.java

 Comments
Comment by mojavelinux [ 27/Jan/11 ]

Two tests have been prepared to demonstrate cases when beans within the same bean archive are not visible to each other.

These tests can be run from the root of the Solder project as follows:

mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest
mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest

These tested use the new Arquillian GlassFish adapter created by Jason Porter and based on the GlassFish REST API.

Comment by Sivakumar Thyagarajan [ 01/Feb/11 ]

Investigation in progress. It appears to be an issue with the way Weld handles accessibility of cyclic references among BeanDeploymentArchives. I have requested the help of Weld engineering team to understand this better, and will update this issue.

Comment by Sivakumar Thyagarajan [ 02/Feb/11 ]

This issue occurs because of the way Weld handles cyclic references among BDAs. I have raised https://issues.jboss.org/browse/WELD-846 to track the Weld side change needed to fix this issue. We will integrate the next available release of Weld that provides a fix for this issue in the next update release of GlassFish 3.1.

Release note/Workaround:
Until then the application could be repackaged such that either:

• Beans in WEB-INF/classes are not used/injected in classes bundled in WEB-INF/lib/*.jar
• All Beans are available as part of WEB-INF/classes [ie collapse the bundled library in WEB-INF/lib/*.jar into WEB-INF/classes].
Comment by Sivakumar Thyagarajan [ 11/Feb/11 ]

FWIW, Weld has fixed the root issue https://github.com/stuartwdouglas/core/tree/WELD-846 in their trunk and this scenario would work again once we integrate the Weld 1.2.0.Beta distribution when it becomes available.

I also tried this scenario against a local build of Weld trunk(attached the weld-osgi-bundle.jar that I used at http://java.net/jira/secure/attachment/44919/weld-osgi-bundle.jar , place this under $INSTALL_ROOT/modules and restart the domain to reproduce this). Comment by mimik789 [ 11/Feb/11 ] I tested provided weld-osgi-bundle.jar in GF3 b_41 (web), and also in latest nightly build - as described in guidliness https://issues.jboss.org/browse/WELD-846 (in exception to that I have to remove content from arquillian.xml config file for jboss - without that test can't be executed, and that I need to replace test with integration-test). ie: 1/ mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest 2/ mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest first test (TypeVisibilityWithinBeanArchiveTest) passes OK but second test (TypeVisibilityForExtensionInNonBeanArchiveTest) FAIL with: org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [BeanClassToRegister] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.solder.test.compat.AnotherBeanClassToRegister.collaborator]. Possible dependencies [[Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default]]] at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:139) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:162) at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:385) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:371) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:394) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190) ... having same issue? Comment by vostok [ 16/Feb/11 ] I'm experiencing a lot of problems in 3.1 versions with my modular project using CDI. It works great (despite CDI memory leaks issues, manually fixed) with 3.0.1 but I cannot deploy it with 3.1 RCs! Tags: 3_1-exclude 3_1-release-notes ^ ----- Solving this bug is being excluded from 3.1 final??? Comment by eratzlaff [ 16/Feb/11 ] It would be nice to have this bug fix for glassfish 3.1 release. Comment by mimik789 [ 21/Feb/11 ] You may be interested with this good news: http://seamframework.org/Community/SeamFacesPersistenceServletCatchProduceNullPointerException#comment149620 for lazy guys and girls: I'm attaching fixed weld-core.jar (weld-osgi-bundle.jar) built from: https://github.com/stuartwdouglas/core/tree/WELD-859 Comment by DiegoCoronel [ 10/Mar/11 ] The jar attached does not resolved my problem. I deleted osgi-cache after change the jar and it does not worked. My war classes cant inject my jar classes. It works fine in glassfish 3.0.1 final. In my specific case i have this scenary myWebModule.war – MyJarProject1.jar (depends:MyFramework, myWebModule.war) – MyJarProject2.jar (depends:MyFramework, MyJarProject1, myWebModule.war) – MyFramework.jar (depends:myWebModule.war) where all jar modules depends on war because they inject EntityManager that is produced by war because it does not worked if jar produce EntityManager. Comment by mojavelinux [ 21/Mar/11 ] Here's an updated test case: https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/visibility/VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest.java Comment by Scott Fordin [ 23/Mar/11 ] Need more info to add issue to 3.1 Release Notes. Comment by Nazrul [ 21/Apr/11 ] It would be useful to look into this issue for 3.1.1 Comment by vrcollins [ 05/May/11 ] I am in the same boat as vostok. I am able to get everything working fine in glassfish 3.0.1. I am using glassfish 3.1 with build 43. I have replaced the weld-osgi-bundle.jar file with the one in this ticket. I am getting the same errors. Comment by toomanyryans [ 10/May/11 ] I think I've been running into this bug. Assume I have two .jars: WEB-INF/lib/jarA WEB-INF/lib/jarB If jarB is dependent on jarA, is it possible they could get scanned in a different order depending on the system I'm deploying to? Specifically, embedded Glassfish on Windows vs normal Glassfish on Linux? I noticed that Glassfish 3.1.1-b04 is using Weld 1.1.1.Final and it fixes my problem. The Weld issue mentioned here (WELD-846) was fixed for 1.1.1.Final, so I think this maybe resolved in Glassfish 3.1.1-b04+. It may be worth testing again if you're watching this issue. Comment by Scott Fordin [ 17/May/11 ] Added issue to 3.1 Known Issues section in 3.1-3.1.1 Release Notes. Comment by scatari [ 24/May/11 ] Fix expected by first week of June. Comment by Sivakumar Thyagarajan [ 09/Jun/11 ] This issue has been fixed since the integration of Weld 1.1.1.Final (that fixes root cause WELD-846) into GlassFish 3.1.1(b4+) and GlassFish trunk. Through svn revision 47397, I have also added the following developer tests to cover this scenario javaee-integration/cdi-servlet-3.0-annotation-with-web-inf-lib/ Comment by cbarragan [ 14/Jul/11 ] As for Glassfish 3.1.1b11 I think the issue might not be solved, although my problem differs from the original issue. I have an EAR with an ejb module and some jars in the lib directory. A dependency in a class that resides in the lib directory cannot be satisfied. This dependency should be solved by a class in my ejb module, but it seems that the class in the ejb module is not visible to the class in the lib directory. Is this another issue? If so, is there an issue related to this problem? Comment by Sivakumar Thyagarajan [ 18/Jul/11 ] @cbarragan: As per section 5.1 of the CDI 1.0 specification: "In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification." In the scenario you had mentioned above: as the EJB module class is not required to be accessible to a jar in the lib directory, the bean class is not available for injection. ### [GLASSFISH-15709] [UB]Accessing encoded URLS throws 403: Forbidden Created: 27/Jan/11 Updated: 07/Jul/11 Resolved: 07/Jul/11 Status: Resolved Project: glassfish Component/s: docs Affects Version/s: 3.1 Fix Version/s: 3.1.1  Type: Bug Priority: Major Reporter: Jothir Ganesan Assignee: Rebecca Parks Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Windows Server 2008 + Oracle Webserver 7u9  Attachments: 15709.html number-app.war Tags: 3_1-release-note-added, 3_1-release-notes  Description  When I deploy and access the attached app (with encoded URL in it) on Oracle webserver 7 in Windows 2008, there is a 403 returned. Message seen in errorlog: for host 10.133.185.48 trying to POST /number-app/TestServlet;jsessionid=397220419959d2534f99f2c71bd4:KsK-;jreplica=instance105;jsessionidversion=2f6e756d6265722d6170, uri-clean reports: CORE4393: malformed path: /number-app/TestServlet;jsessionid=397220419959d2534f99f2c71bd4:KsK-;jreplica=instance105;jsessionidversion=2f6e756d6265722d617070:0 Message from access log: 10.133.185.48 - - [26/Jan/2011:23:03:54 -0800] "GET /number-app/TestServlet HTTP/1.1" 200 500 10.133.185.48 - - [26/Jan/2011:23:03:54 -0800] "POST /number-app/TestServlet;jsessionid=6485c8ea4f94b014d8efd798e7f1:W6zw;jreplica=instance104;jsessionidversion=2f6e756d6265722d617070:0 HTTP/1.1" 403 142 Attached the app used in the test.  Comments  Comment by sonymanuel [ 27/Jan/11 ] To reproduce the issue : Disable cookies in the browser Deploy the app to the cluster and export the lb config to web server instance. Access http://:/number-app/TestServlet Comment by kshitiz_saxena [ 27/Jan/11 ] This request is rejected by web server itself and throws forbidden error. This has nothing to do with load-balancer plugin. May be this is an issue with web server or some configuration issue. Will try to get some information from web server team. Comment by kshitiz_saxena [ 01/Feb/11 ] This issue is caused by web server fix for not allowing uri having ":" in its value. As a workaround, you need to change following entry in obj.conf : Replace : PathCheck fn="uri-clean" With : PathCheck fn="uri-clean" This will not call uri-clean for requests being serviced by GlassFish load-balancer plugin. Please note this change is only needed for url-rewriting case. Assigning to documentation team to capture it in load-balancer documentation and release note this issue. Comment by Scott Fordin [ 11/Feb/11 ] Looking at the comments here, is this really a load balancer issue? Or, to ask a different question, is this solely a Release Notes issue in the LB section, or does the topic need to be added to the HAAG? Comment by Scott Fordin [ 17/Mar/11 ] Second request: I still need more information to document this issue. Comment by Scott Fordin [ 16/May/11 ] Upon further examination, I believe this is only a Release Notes issue. I've added the issue to the 3.1-3.1.1 Release Notes, and removed the "need more info" tag. Comment by scatari [ 06/Jun/11 ] Fixing the target version to include the correct build number. Comment by Paul Davies [ 07/Jul/11 ] This issue affects the Release Notes, which is an unbundled document. Therefore, the fix for this issue is not related to any build. I have set the Fix Version to 3.1.1. The attached file contains the fix. This fix will be published in the next library update. Comment by Paul Davies [ 07/Jul/11 ] According to the comments on this issue, the fix affects only the Release Notes. As the Release Notes have been updated to describe this issue, this issue is now fixed. The update is in the attached file and will be published in the next library update. ### [GLASSFISH-15654] Need to be able to add the iWS's bin and LBConfigurator's lib to system path during LoadBalancer Configurator last stage of installation. Created: 21/Jan/11 Updated: 19/Dec/16 Resolved: 23/May/11 Status: Resolved Project: glassfish Component/s: load_balancer Affects Version/s: 3.1_dev Fix Version/s: 3.1_dev  Type: Bug Priority: Major Reporter: Homer Yau Assignee: Rebecca Parks Resolution: Duplicate Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Tests Windows 2008 R2  Tags: 3_1, 3_1-exclude, 3_1-need_more_info, 3_1-release-notes, glasfish-3, glassfish, plugin, ssl  Description  Need to be able to add the iWS's bin and LBConfigurator's lib to system path during LoadBalancer Configurator installation stage and give user information to reboot to take affect. Currently, during LB configurator installation if there are issue finding the path or adding the path, it will give user an warning message. And the warning message are there to guide user to add to the system path and reboot We need to fix this issue for a better user experience. Automatically add the require path ( iWS's bin and LBConfigurator's lib) to system path for lbplugin to work correctly.  Comments  Comment by Scott Fordin [ 23/Mar/11 ] Need more info to add issue to 3.1 Release Notes. Comment by kshitiz_saxena [ 23/May/11 ] This issue is duplicate of GLASSFISH-15647 : http://java.net/jira/browse/GLASSFISH-15647 Comment by Scott Fordin [ 23/May/11 ] Does this issue still need to be added to 3.1 Release Notes? The LB configuration instructions in the HA Admin Guide have undergone quite a lot of rework since this issue was created. Comment by Scott Fordin [ 31/May/11 ] Reassigning to Rebecca Parks. ### [GLASSFISH-15645] [UB][RM-HA] [to-be-release-noted] RM InOrder Delivery mode tests do not work correctly. Created: 20/Jan/11 Updated: 19/Dec/16 Resolved: 17/Mar/11 Status: Resolved Project: glassfish Component/s: docs Affects Version/s: 3.1_dev Fix Version/s: 3.1  Type: Bug Priority: Major Reporter: varunrupela Assignee: Scott Fordin Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Issue Links:  Dependency depends on GLASSFISH-15828 [Test Issue] On some GF-HA functional... Open depends on WSIT-1521 HA RM in-order test clients do not wo... Open Tags: 3_1-release-note-added, 3_1-release-notes  Description  The following Issue needs to be release noted for GF 3.1: http://java.net/jira/browse/WSIT-1521 This affects GF HA. Reliable Messaging, InOrder Delivery mode has not been tested with HA (not supported).  Comments  Comment by sonymanuel [ 24/Jan/11 ] Changing to docs. Comment by Scott Fordin [ 25/Feb/11 ] Need more information to document in Release Notes. Comment by varunrupela [ 01/Mar/11 ] It needs to be release noted that GlassFish HA does not support Webservices that use Reliable Messaging in InOrder Delivery mode. Do let us know if any specific information is required. Comment by Scott Fordin [ 03/Mar/11 ] Yes, please. 1) More detail about problem. 2) Any workarounds? Comment by varunrupela [ 07/Mar/11 ] What needs to be release noted is that "The Metro Reliable Messaging in InOrder Delivery mode has not been tested for High-Availability and thus is not a supported feature." The feature may be working but has not been tested and hence not supported. Thus there isn't a need to mention workarounds. Comment by Scott Fordin [ 17/Mar/11 ] Added topic to Restrictions and Deprecated Functionality section of 3.1 Release Notes. I added it to this section rather than the Known Issues section because it seems to be more of a restriction than a bug, per se. Comment by Scott Fordin [ 24/Mar/11 ] Added "3_1-release-note-added" tag. ### [GLASSFISH-15633] Admin Console: intermittent Blank Screen Created: 20/Jan/11 Updated: 19/Dec/16 Resolved: 29/Mar/13 Status: Resolved Project: glassfish Component/s: admin_gui Affects Version/s: 3.1_dev Fix Version/s: None  Type: Bug Priority: Minor Reporter: Harshad Vilekar Assignee: Jason Lee Resolution: Cannot Reproduce Votes: 2 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified  Attachments: admin-console-blank-b37.jpg admin-gui-blank-help-screen.jpg Tags: 3_1-release-note-added, 3_1-release-notes, 3_1_1-review  Description Admin GUI sometimes simply displays "blank screen". The bottom status bar of the browser window says "Done". Workaround: • To refresh Help screen - Click on Admin Console Help button. • To refresh main browser window, click Shift - Reload. This is seen (once in a while) on some screens - including Console Main Screen, Help Windows and sometimes "restart required" details screen. I bumped into this again today. Screen shot for blank help window (b38) and blank main window (b37) attached. I've seen this with OEL5 and Solaris 10 (Firefox 3.6.10). Sometimes, there is exception thrown in the server log (not sure if it's related). see below. ========================= [#|2011-01-20T15:21:56.347-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=123;_ThreadName=Thread-1;|SEC1011: Security Service(s) Started Successfully|#] [#|2011-01-20T15:21:57.971-0800|INFO|oracle-glassfish3.1|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=21;_ThreadName=Thread-52;|Initializing Mojarra 2.1.0 (FCS b10) for context ''|#] [#|2011-01-20T15:21:58.073-0800|INFO|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=22;_ThreadName=admin-thread-pool-4848(5);|Listening to REST requests at context: /management/domain|#] [#|2011-01-20T15:21:57.971-0800|INFO|oracle-glassfish3.1|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=21;_ThreadName=Thread-1;|Initializing Mojarra 2.1.0 (FCS b10) for context ''|#] [#|2011-01-20T15:21:58.073-0800|INFO|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=22;_ThreadName=Thread-1;|Listening to REST requests at context: /management/domain|#] [#|2011-01-20T15:22:00.782-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=123;_ThreadName=Thread-52;|WEB0671: Loading application [__admingui] at [/]|#] [#|2011-01-20T15:22:00.784-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=123;_ThreadName=Thread-52;|CORE10010: Loading application __admingui done in 8,244 ms|#] [#|2011-01-20T15:22:00.785-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=123;_ThreadName=Thread-52;|The Admin Console application is loaded.|#] [#|2011-01-20T15:22:00.782-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=123;_ThreadName=Thread-1;|WEB0671: Loading application [__admingui] at [/]|#] [#|2011-01-20T15:22:00.784-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=123;_ThreadName=Thread-1;|CORE10010: Loading application __admingui done in 8,244 ms|#] [#|2011-01-20T15:22:00.785-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.admin.adapter|_ThreadID=123;_ThreadName=Thread-1;|The Admin Console application is loaded.|#] [#|2011-01-20T15:22:03.788-0800|WARNING|oracle-glassfish3.1|org.apache.catalina.connector.Request|_ThreadID=22;_ThreadName=admin-thread-pool-4848(5);|PWC4011: Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called|#] [#|2011-01-20T15:22:03.788-0800|WARNING|oracle-glassfish3.1|org.apache.catalina.connector.Request|_ThreadID=22;_ThreadName=Thread-1;|PWC4011: Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called|#] [#|2011-01-20T15:22:13.379-0800|INFO|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=22;_ThreadName=admin-thread-pool-4848(5);|Admin Console: Initializing Session Attributes...|#] [#|2011-01-20T15:22:13.379-0800|INFO|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=22;_ThreadName=Thread-1;|Admin Console: Initializing Session Attributes...|#] [#|2011-01-20T15:22:14.814-0800|WARNING|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=23;_ThreadName=Thread-61;|Cannot create update center Image for /export/home/glassfish3; Update Center functionality will not be available in Admin Console|#] [#|2011-01-20T15:22:14.814-0800|WARNING|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=23;_ThreadName=Thread-1;|Cannot create update center Image for /export/home/glassfish3; Update Center functionality will not be available in Admin Console|#] [#|2011-01-20T15:32:05.647-0800|WARNING|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=86;_ThreadName=admin-thread-pool-4848(2);|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception java.lang.IllegalStateException at org.apache.catalina.connector.ResponseFacade.reset(ResponseFacade.java:369) at com.sun.faces.context.ExternalContextImpl.responseReset(ExternalContextImpl.java:821) at com.sun.faces.context.ExceptionHandlerImpl.throwIt(ExceptionHandlerImpl.java:251) at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:141) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:396) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)  #] [#|2011-01-20T15:32:05.647-0800|WARNING|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=86;_ThreadName=Thread-1;|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception java.lang.IllegalStateException at org.apache.catalina.connector.ResponseFacade.reset(ResponseFacade.java:369) at com.sun.faces.context.ExternalContextImpl.responseReset(ExternalContextImpl.java:821) at com.sun.faces.context.ExceptionHandlerImpl.throwIt(ExceptionHandlerImpl.java:251) at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:141) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:396) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)  #] ====================== Please note that this is an intermittent issue. Not always reproducible. Please document this - if root cause is not identified in time for 3.1 release.  Comments  Comment by Harshad Vilekar [ 20/Jan/11 ] Update: Steps to duplicate the exception: press the "Help" button more than once with a short pause. Comment by Chris Kasso [ 20/Jan/11 ] This is not a P3 issue. It is being downgraded to P4. If Anissa finds a simple fix we can still consider it for 3.1. If a fix can not be found then we can cover this issue in the Release Notes. If the blank screen can be reproduces in more mainstream scenarios please upgrade the bug to a higher priority. Comment by Harshad Vilekar [ 26/Jan/11 ] Looks like Blank screen and IllegalStateException are two separate issues. Created http://java.net/jira/browse/GLASSFISH-15692 for tracking: "PWC1406: Servlet.service() for servlet FacesServlet threw exception java.lang.IllegalStateException" Comment by shaline [ 26/Jan/11 ] I see this blank screen as well , and cannot consistently reproduce. While working in GUI, if we restart the domain in CLI, and click reload button in the browser, sometimes I see this blank screen, and always have to do "shift + reload" to launch the Console. But I do not see any Exceptions in the server.log Comment by lidiam [ 16/Feb/11 ] I consistently see this issue in Firefox on Windows XP after changing Glassfish version, e.g. removing old one and unzipping new distribution. Have to select clearing cache, cookies, form and search history and active logins in order to get the GUI displayed (and sometimes repeatedly). Recently noticed that in Firefox the default "Time range to clear" is "Last hour". Changed to "Today" and I can at least get the Console displayed again. Comment by Scott Fordin [ 13/Apr/11 ] Added issue to 3.1 Release Notes. Comment by Nazrul [ 20/Apr/11 ] Are we able to reproduce this? If yes, we should look into it for 3.1.1. Getting blank screens is not a good user experience. Comment by Nazrul [ 21/Apr/11 ] Few people raised this issue today. It would be good to take a look a this issue during 3.1.1 Comment by Anissa Lam [ 21/Apr/11 ] Getting help from Jason Comment by Jason Lee [ 22/Apr/11 ] I am unable to reproduce this scenario. Are there consistent/reliable steps to reproduce? Comment by guyost [ 22/Aug/11 ] Hello, I don't know if have this problem or not. I'm using Glassfish 3.1.1 on Windows Server 2008 32bit. I started getting this problem few days ago : I connect to www.kyuubibarre.com:4848 to access the console, immediatly after starting the domain Since it's the first time, the messages shows something like thats "Console is loading..." After few seconds, the message shows "Console is loaded, if this page doesn't reload, please reload manually" (not sure of the exact text... but I think you know what I mean) Then nothing happens. So I reload the page, and I get a blank page. I tried to clear the cache of my browser, I even change browser, and even computer... Nothing changes. I tried to access the login page manually : www.kyuubibarre.com:4848/login.jsf ==> blank page again. I restarted the domain, the same scenario happens. In the server log file, the last line I have is : The Admin Console application is loaded And then, nothing. The application deployed on this server are correctly working. I have different domain instances, all applications on all domains are working well, but all admin consoles show a blank page. If you need more details, just ask me. I will provide what you need to solve it. Comment by kpasgma [ 20/Mar/12 ] I am having the same issue as guyost. The only way I can fix it is to restart the complete server. Comment by thomask [ 23/May/12 ] I was having the same issue; however, I am unsure whether this will help as it was not on an install nor was it intermittant. I NEVER had this problem until I updated my secutiry settings in my domain's server settings node. I am new to GlassFish and may have just used it incorrectly. The issue I think was due to me setting 'Default Principa'l which I had set to "admin", I had also created some user groups and users with the same name as those groups under the file realm. When I removed the settings the problem disappeared. Though, I cannot recreate the problem but have noticed that when I orignally created groups and users that users were automatically being assigned to all groups? If this is useless delete me! Comment by ssemmandarobert [ 28/Feb/13 ] Hello, I am facing this issue and i have no work around, even after i reload in the page in the browser same issue. How did you solve it ? Keep in mind i have not updated or installed any new glassfish server, all i did was to restart the domain via command line when the window admin console was still logged in. I have cleared my browser cache and history . Thanx Comment by Anissa Lam [ 01/Mar/13 ] Which GlassFish version are you using ? This bug was filed against 3.1, and I haven't seen this for a long time. If you are using 3.1, can up upgrade to later release ? which browser are you using ? can you try another browser ? Comment by Jason Lee [ 29/Mar/13 ] We have been unable to reproduce this issue. If this issue recurs, please reopen the bug with steps to reproduce. ### [GLASSFISH-15571] Create Resource Adapter Config is throwing an exception if jms is already started Created: 14/Jan/11 Updated: 21/Sep/15 Status: Open Project: glassfish Component/s: orb Affects Version/s: None Fix Version/s: 4.1.1  Type: Bug Priority: Major Reporter: sumasri Assignee: Harshad Vilekar Resolution: Unresolved Votes: 1 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified  Tags: 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_2-exclude  Description  Start the JMS. In GUI, try to create a resource adapter config using jmsra and thread pool as "http-thread-pool". It is throwing an exception in the server log. Steps to reproduce the issue : 1)./bin/asadmin jms-ping 2) In GUI, create a resource adapter config with resource adapter name as jmsra and thread pool as http-thread-pool. Then, it throws an exception. Exception in server log : [#|2011-01-14T14:55:14.369+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.work|_ThreadID=333;_ThreadName=Thread-2;|Thread-pool [ http-thread-pool ] not found|#] [#|2011-01-14T14:55:14.370+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.work|_ThreadID=333;_ThreadName=Thread-2;|An error occurred during instantiation of the work manager for resource-adapter [ jmsra ] com.sun.appserv.connectors.internal.api.ConnectorRuntimeException at com.sun.enterprise.connectors.work.CommonWorkManager.(CommonWorkManager.java:118) at com.sun.enterprise.connectors.work.WorkManagerFactory.createWorkManager(WorkManagerFactory.java:125) at com.sun.enterprise.connectors.work.WorkManagerFactory.getWorkManagerProxy(WorkManagerFactory.java:196) at com.sun.enterprise.connectors.ConnectorRuntime.getWorkManagerProxy(ConnectorRuntime.java:1129) at com.sun.enterprise.connectors.BootstrapContextImpl.initializeWorkManager(BootstrapContextImpl.java:161) at com.sun.enterprise.connectors.BootstrapContextImpl.(BootstrapContextImpl.java:103) at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:126) 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:211) at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:345) at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.reCreateActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:541) at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.addResourceAdapterConfig(ResourceAdapterAdminServiceImpl.java:494) at com.sun.enterprise.connectors.ConnectorRuntime.addResourceAdapterConfig(ConnectorRuntime.java:1195) at com.sun.enterprise.resource.deployer.ResourceAdapterConfigDeployer.deployResource(ResourceAdapterConfigDeployer.java:86) at com.sun.enterprise.resource.deployer.ResourceAdapterConfigDeployer.redeployResource(ResourceAdapterConfigDeployer.java:117) at org.glassfish.javaee.services.ResourceManager$PropertyChangeHandler.handleChangeEvent(ResourceManager.java:378) at org.glassfish.javaee.services.ResourceManager$PropertyChangeHandler.changed(ResourceManager.java:328) at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:329) at org.glassfish.javaee.services.ResourceManager.changed(ResourceManager.java:275) at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:376) at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:366) at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:256) at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:254) 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) Caused by: com.sun.corba.ee.spi.orbutil.threadpool.NoSuchThreadPoolException at org.glassfish.enterprise.iiop.util.S1ASThreadPoolManager.getThreadPool(S1ASThreadPoolManager.java:217) at com.sun.enterprise.connectors.work.CommonWorkManager.(CommonWorkManager.java:111) ... 29 more

 Comments
 Comment by Jagadish [ 14/Jan/11 ] ThreadPoolManager.getThreadPool() seems to throw the exception. ThreadPoolManager only has "thread-pool-1" when the method "getThreadPool" is called. Transferring to Ken for further investigation. Steps to reproduce : asadmin jms-ping asadmin create-resource-adapter-config --threadpoolid http-thread-pool jmsra will show the reported exception in server.log Comment by Ken Cavanaugh [ 14/Jan/11 ] It looks like the issue may be in S1ASThreadPoolManager (which is in orb/orb-connector). This class has a static initializer that reads the ThreadPool config data from the iiop service and network listener config beans. But there is no way to add a new ORB threadpool after the initial configuration is read. It is also not clear to me from the test case how you expect "http-thread-pool" to be created. Is this an ORB threadpool or a Grizzly threadpool? GF 3.1 has TWO distinct threadpool implementations currently. Which one does create-resource-adapter-config expect to use? How does the http-thread-pool get created if it does not already exist? I am excluding this from 3.1 because I cannot investigate it or fix it before the RC1 deadline. It is not even clear if this is something that should be fixed at this point. Comment by Jagadish [ 17/Jan/11 ] Hi Ken, > It looks like the issue may be in S1ASThreadPoolManager (which is in orb/orb-connector). > This class has a static initializer that reads the ThreadPool config data from > the iiop service and network listener config beans. But there is no way to > add a new ORB threadpool after the initial configuration is read. Yes, whenever we create a thread-pool, we restart the server. > It is also not clear to me from the test case how you expect "http-thread-pool" to be created. > Is this an ORB threadpool or a Grizzly threadpool? Connector container uses ORB thread pool (work) API and hence its always ORB thread pool. > GF 3.1 has TWO distinct threadpool implementations currently. > Which one does create-resource-adapter-config expect to use? ORB thread pool. In GlassFish 2.x and before, a resource-adapter can use any of the configured thread-pools in the system. > How does the http-thread-pool get created if it does not already exist? http-thread-pool configuration is present in a all domains by default. > I am excluding this from 3.1 because I cannot investigate it or fix it before > the RC1 deadline. It is not even clear if this is something that should be fixed at this point. I am able to create a new thread pool, restart server, configure the resource-adapter to use new thread pool successfully. However, I do not see http-thread-pool and admin-thread-pool in the list of thread pools of S1ASThreadPoolManager. Is this by design ? If it is by design, probably we should document it. eg: Following thread-pools are grizzly thread pools and will not be available for ORB thread pool clients/users. http-thread-pool, admin-thread-pool I am adding '3_1-release-notes' tag to the issue so that it is documented/release-noted. Could you please provide appropriate documentation changes for the same ? Comment by Jagadish [ 17/Jan/11 ] Update : I see that IIOPUtils exluding thread-pools that are used by http-listener (network-listener) while initializing ORB thread-pools. Comment by Scott Fordin [ 23/Mar/11 ] Need more info to add issue to 3.1 Release Notes. Comment by Jagadish [ 31/Mar/11 ] There are two thread pool implementations from GlassFish 3.0 ie., grizzly based thread-pool and ORB based thread-pool. "create-resource-adapter-config" takes a thread-pool id as parameter which is based on ORB thread-pool. Also refer, create-thread-pool command to create new thread-pools. ORB thread-pool, when initialized will verify whether an "thread-pool" is used by grizzly and will initialize the thread-pool only if grizzly is already not using the configuration. So, there need to be a documentation stating that ORB thread pool manager will exclude any defined thread-pool configuration in the system if its already used by grizzly thread pool manager. Comment by Scott Fordin [ 13/Apr/11 ] Added issue to 3.1. Release Notes. Comment by Nazrul [ 21/Apr/11 ] It would be useful to look into this issue during 3.1.1 Comment by scatari [ 25/Jun/11 ] Marking it as to be considered after 3.1.1. Comment by Tom Mueller [ 07/Feb/13 ] Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.

### [GLASSFISH-15558] Caching JMS session in a session bean causes errors when invoked by a MDB when under load Created: 13/Jan/11  Updated: 19/Dec/16

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_dev
Fix Version/s: 4.1.1

 Type: Bug Priority: Major Reporter: Nigel Deakin Assignee: Nigel Deakin Resolution: Unresolved Votes: 3 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified

 Attachments: ServerLog.odt     TransactionTests.zip Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1_1-scrubbed, 3_1_2-exclude

 Description
 This issue was originally reported by a user on the GlassFish developer list. Here is the thread: http://www.java.net/forum/topic/glassfish/glassfish/jms-and-transaction-issue The issue can be summarised as follows: a MDB consumes a message from an inbound queue, updates a database then invokes a session bean which sends a message to an outbound queue. If 40 messages are placed on the inbound queue then we see a variety of messages in the server log (see that thread), including this one: 625+0000|SEVERE|glassfish3.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=36;_ThreadName=Thread-1;|commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:950872495901869318 and onePhase:false due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsserver.util.BrokerException: Bad transaction state transition. Cannot perform operation COMMIT_TRANSACTION(46) (XAFlag=0x0:TMNOFLAGS) on a transaction in state COMPLETE(4).|#] The error occurs ONLY if the session bean caches its JMS connection, session and producer in a field of the bean. This is valid, though it is contrary to the conventional practice which is to create the connection, use it, and close the connection every time the session bean is invoked. If these objects are not cached then this bug is NOT seen. This bug therefore has a workaround. The issue can be reproduced using JMS only (i.e. not using a database), though to see exactly the same errors as the user reported it is necessary to force the use of two-phase commits. A simple NetBeans application is attached which demonstrates the issue. This consists of a Enterprise Application "TransactionTests" which is composed of a ejb application "TransactionTests-ejb" and a web application "TransactionTests-war". Steps to reproduce: 1. Install the latest version of GlassFish 3.1 (I used build 37) 2. Before starting GlassFish, edit domain.xml to set the JVM option -Dimq.jmsra.isSameRMAllowed=false . This is needed to force two-phase transactions to be used. (If this is not done the application will still fail but you will get different errors). 3. Use NetBeans to build the application (which is an ear cotaining an ejb and a web app) and deploy it in GlassFish. 4. Visit http://localhost:8080/TransactionTests-war/ and click on "Run MDB Test 1". This causes a servlet to send 40 messages to the inbound queue. 5. Inspect the server log for errors

 Comments
 Comment by Nigel Deakin [ 13/Jan/11 ] The attached file ServerLog.odt is an extract from the server log, which includes logging in DirectXAResource and in the application. Note particularly Thread 36 (highlighted in green) and Thread 51 (highlighted in red). This suggests that the session bean instance used by thread 36 was reused by thread 51 after the business method returned but before the MDB returned and the transaction was committed. This meant that the same JMS session object was being used by two threads at the same time, which caused the error. (Full disclosure: to create this logging a modified version of MQ was used with all use to System.out() in DirectXAResource changed to use JDK logging. This was necessary to ensure that such log messages were reported using the correct thread) Comment by Nigel Deakin [ 14/Jan/11 ] This behaviour is also seen in GlassFish 2.1.1, so this is not a regression. There's also a workaround (and the workaround is generally considered better practice than the problem case). So this bug doesn't need to be fixed now, so setting the 3_1-exclude tag. Comment by Nigel Deakin [ 14/Jan/11 ] Have created documentation bug http://java.net/jira/browse/GLASSFISH-15579 to record this in the release note for 3.1. Comment by Paul Davies [ 14/Jan/11 ] For the GlassFish 3.1 release notes add the following information: A stateless session bean should not save JMS connections or sessions in fields of the bean. Applications that do so may encounter errors. To avoid this issue, if a stateless session bean's business method requires the use of a JMS connection and session then the business method should create the JMS connection and session, use it to send or receive messages, and then close the connection and session before returning. This is GlassFish issue 15558. Comment by theodor.richard [ 14/Jan/11 ] I'm the user who initially reported this issue on the mailing list. A problem with not caching the connection is that the maximum number of connections is reached quickly. I'm seeing the following exceptions in the log when sending 50 messages in a for loop, i.e. the method that acquires and releases the JMS connection is invoked 50 times in a row: com.sun.messaging.jms.JMSException: MQRA:DCF:allocation failure:createConnection:Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections. My max connection pool size has the default size of 32. Comment by Nigel Deakin [ 17/Jan/11 ] @theodor.richard: If you believe that managed connections are not being returned correctly to the pool (and this isn't because your pool simply isn't big enough), then please log this as a separate issue or raise it on the user list. Please keep this issue for discussions of the effect of caching the connection, session and producer. Comment by Nigel Deakin [ 25/Jan/11 ] Analysis of the test case shows that the cause of the problem is that the container is reusing the session bean instance (and hence the connection's XAResource instance) after the business method has returned but before the transaction has been committed. It is legal for the container to reuse the stateless session bean instance before the transaction has been committed: the EJB spec, section 4.7 "Stateless Session Beans" states that "the container may interleave requests from multiple transactions to the same instance". However doing so causes errors in the JMSRA resource adapter, because it is designed on the basis that the same XAResource instance is used for start, end, prepare and commit and that the instance will not be reused until the transaction is committed or rolled back. That is a breach of the JCA 1.5 spec, which states in section 7.3.2.1 "Implementation" that "A transaction manager can use any XAResource instance (if it refers to the proper resource manager instance) to initiate transaction completion. The XAResource instance used during the transaction completion process need not be the one initially enlisted with the transaction manager for this transaction" This has been logged as internal (bugs.sun.com) bug 7014537. Comment by jthoennes [ 14/Apr/11 ] Hello Nigel, as we heavily use that kind of scenario, I would like to ask whether this issue will be fixed for 3.1.1 without raising a service request. A quick answer is highly appreciated. Thanks, Jörg Comment by Nigel Deakin [ 14/Apr/11 ] This is currently scheduled for 3.2, though, as always, I can't make commitments as to the contents of future releases. If you have a support licence and this issue is causing a problem them please contact your support representative (and let me know you've done so) since this would definitely affect the priority we give to fixing it. Nigel Comment by jthoennes [ 14/Apr/11 ] In reply to comment #9: > If you have a support licence and this issue is causing a problem them please > contact your support representative (and let me know you've done so) since this > would definitely affect the priority we give to fixing it. Thanks, Nigel. Yes, we have a support contract. What do you need if I file a service request on My Oracle Support (MOS). Do you have access to the service requests submitted? Cheers, Jörg Comment by Scott Fordin [ 15/Apr/11 ] Added issue to 3.1 Release Notes. Comment by Nazrul [ 21/Apr/11 ] It would be good to take a look at this issue for 3.1.1 Comment by Nigel Deakin [ 03/May/11 ] @jthoennes - Yes, please file an issue with Oracle support as you suggest. There is a separate engineering team to resolve customer issues, so raising it with support increases the resources available to address this issue. Comment by Nigel Deakin [ 03/May/11 ] I have reviewed this bug for 3.1.1 and decided not to fix it in that version for the following reasons: This bug is in older versions of GlassFish (including GlassFish 2.1.1) and so is not a regression There is a workaround (see earlier comment) The fix would require significant changes to the XAResource implementation classes in the JMSRA resource adapter. In addition to the work involved it would require a lot of testing to be sure that it does not introduce a regression. 3.2 will have much more testing than 3.1.1 and so, given that this is an old bug which has a workaround, I would like to defer fixing this bug until 3.2 so it can be properly tested. Removing the 3_1_1-review tag. @jthoennes - note that if you raise this issue with Oracle support this will still be reviewed by Oracle sustaining. Comment by jthoennes [ 27/May/11 ] Filed Oracle Service Request "SR 3-3705874175: Resolve GLASSFISH-15558 for Glassfish 3.1.1" for this issue. Comment by marina vatkina [ 16/Nov/11 ] Re EJB container behavior: In our current implementation, bean instances are returned to pool at the end of method invocation. If we were to to delay it till the termination of tx, we would need more instances because transaction can last much longer than a single method invocation. Comment by Nigel Deakin [ 14/Dec/11 ] Adding 3_1_2-exclude tag. Excluding from 3.1.2 for the same reason it was excluded from 3.1.1 (see my comment above).

### [GLASSFISH-15505] [UB]docs: need to represent partial Connector Architecture Specification support in Web Profile Created: 10/Jan/11  Updated: 29/Mar/11

Status: In Progress
Project: glassfish
Component/s: webpages
Affects Version/s: None
Fix Version/s: None

 Type: Bug Priority: Major Reporter: Jagadish Assignee: Alexis MP Resolution: Unresolved 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
 Raising this issue based on the forum discussion : http://www.java.net/forum/topic/glassfish/glassfish/unsupported-features-displayed-glassfish In section titled "Java EE 6 standards" of Release Notes (3.1) please make the following changes. Also applicable for the following pages : http://glassfish.java.net/downloads/3.0.1-final.html http://glassfish.java.net/downloads/v3-final.html In the row for "Connector Architecture 1.6", indicate yes against web profile but with an footnote that indicates "Standalone Connector 1.6 Container only". Against Full Profile, retain the current value.

 Comments
 Comment by Scott Fordin [ 25/Mar/11 ] Added 3_1-release-notes tag for tracking purposes. Comment by Scott Fordin [ 25/Mar/11 ] Updated table in 3.1 Release Notes, and added "3_1-release-note-added" tag. Reassigned to Paul Davies because I don't own the public Web pages for which the change also needs to be made. Paul may know who owns these pages. If not, to whom should this issue be reassigned? Comment by Paul Davies [ 29/Mar/11 ] Reassigned to alexismp, who is responsible for the GF site web pages. Comment by Alexis MP [ 29/Mar/11 ] Taking over the issue but missing some context (the forum link is now a 404). Are you saying 3.0.1 and 3.0 download pages need to be changed but not http://glassfish.java.net/downloads/3.1-final.html ? The table rows maps to IPS packages installed in the distro. Which connector package is in the Web profile distro?

### [GLASSFISH-15482] Domain fails to stop after console loaded (with secure admin enabled) Created: 07/Jan/11  Updated: 19/Dec/16  Resolved: 10/Jan/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_dev
Fix Version/s: None

 Type: Bug Priority: Critical Reporter: Chris Kasso Assignee: Chris Kasso Resolution: Won't Fix Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: S11/x86

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

 Description

Server fails to stop when in secure admin mode and Console has been loaded.

To reproduce this problem:

1) Install b36
2) start-domain
3) enabled-secure-admin
4) stop-domain
5) start-domain
6) load Admin Console
7) stop-domain

In step 7 asadmin will report:

ouch: ./asadmin stop-domain
CLI306 Warning - server is not running.
Command stop-domain executed successfully.

and the following will be in the server log:

[#|2011-01-07T11:46:15.563-0800|WARNING|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=24;_ThreadName=admin-thread-pool-4848(5);|processorTask.exceptionSSLcert
javax.net.ssl.SSLHandshakeException: renegotiation is not allowed
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:621)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:667)
at com.sun.grizzly.util.SSLUtils.doPeerCertificateChain(SSLUtils.java:559)
at com.sun.grizzly.filter.SSLReadFilter.doPeerCertificateChain(SSLReadFilter.java:340)
at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:153)
at com.sun.grizzly.tcp.Request.action(Request.java:430)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getAttribute(GrizzlyRequest.java:835)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getUserPrincipal(GrizzlyRequest.java:1834)
at com.sun.enterprise.v3.admin.AdminAdapter.authenticate(AdminAdapter.java:266)
at com.sun.enterprise.v3.admin.AdminAdapter.authenticate(AdminAdapter.java:309)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:218)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

 #]

[#|2011-01-07T11:46:15.569-0800|SEVERE|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=24;_ThreadName=admin-thread-pool-4848(5);|service exception
java.lang.RuntimeException: ClientAbortException: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:254)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: ClientAbortException: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:439)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:251)
... 17 more
Caused by: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.grizzly.util.SSLOutputWriter.flushChannel(SSLOutputWriter.java:98)
at com.sun.grizzly.ssl.SSLOutputBuffer.flushChannel(SSLOutputBuffer.java:138)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:398)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:376)
at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1236)
at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:164)
at com.sun.grizzly.tcp.Response.action(Response.java:268)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:434)
... 20 more

 #]

[#|2011-01-07T11:46:45.592-0800|WARNING|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=22;_ThreadName=admin-thread-pool-4848(4);|processorTask.exceptionSSLcert
javax.net.ssl.SSLHandshakeException: renegotiation is not allowed
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:621)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:667)
at com.sun.grizzly.util.SSLUtils.doPeerCertificateChain(SSLUtils.java:559)
at com.sun.grizzly.filter.SSLReadFilter.doPeerCertificateChain(SSLReadFilter.java:340)
at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:153)
at com.sun.grizzly.tcp.Request.action(Request.java:430)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getAttribute(GrizzlyRequest.java:835)
at com.sun.grizzly.tcp.http11.GrizzlyRequest.getUserPrincipal(GrizzlyRequest.java:1834)
at com.sun.enterprise.v3.admin.AdminAdapter.authenticate(AdminAdapter.java:266)
at com.sun.enterprise.v3.admin.AdminAdapter.authenticate(AdminAdapter.java:309)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:218)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

 #]

[#|2011-01-07T11:46:45.594-0800|SEVERE|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=22;_ThreadName=admin-thread-pool-4848(4);|service exception
java.lang.RuntimeException: ClientAbortException: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:254)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:818)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1008)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: ClientAbortException: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:439)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:251)
... 17 more
Caused by: java.io.IOException: SSLOutputWriter: CLOSED
at com.sun.grizzly.util.SSLOutputWriter.flushChannel(SSLOutputWriter.java:98)
at com.sun.grizzly.ssl.SSLOutputBuffer.flushChannel(SSLOutputBuffer.java:138)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:398)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:376)
at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1236)
at com.sun.grizzly.ssl.SSLProcessorTask.action(SSLProcessorTask.java:164)
at com.sun.grizzly.tcp.Response.action(Response.java:268)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:434)
... 20 more

 #]

 Comments
 Comment by Tom Mueller [ 07/Jan/11 ] This appears to be due to running with a JDK that is less than version 1.6.0_22. Can you please check this? Comment by Nazrul [ 10/Jan/11 ] This is most likely due to JDK update 22 issue. Lowering the priority. If we have a problem with update 22, please raise the priority. Comment by Chris Kasso [ 10/Jan/11 ] I was using 21. I upgraded to 23 and the problem is not reproducible. I've marked this issues with 3_1-release-notes to ensure we stress that bad things can happen in update 21 or earlier is used. (I suspect this is already stressed in the docs). Comment by Scott Fordin [ 15/Apr/11 ] Issue added to 3.1 Release Notes.

### [GLASSFISH-15456] [UB]Release note security permissions required for CDI applications Created: 06/Jan/11  Updated: 19/Dec/16  Resolved: 25/Mar/11

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

 Type: Task Priority: Major Reporter: Sivakumar Thyagarajan Assignee: Scott Fordin 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
 Please release note the following for 3.1 See GLASSFISH-15078 [1] for more information. CDI-enabled Java EE applications that are deployed in a GF3.1 domain/cluster, which has security manager enabled, have to add the following Permissions for the deployed application. Adding permissions for an application is described in http://docs.sun.com/app/docs/doc/820-7695/beabz?l=en&a=view grant codeBase "file:${com.sun.aas.instanceRoot}/applications/[ApplicationName]" { permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; For example, for a CDI application, say foo.war, add the following permissions to server.policy, restart domain/cluster and then deploy and use the application. grant codeBase "file:${com.sun.aas.instanceRoot} /applications/foo" { permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; These additional Permissions are not needed when the security manager is disabled.

 Comments
 Comment by Paul Davies [ 11/Jan/11 ] Not really a bug but a task. Reassigned to Release Notes owner. Prefixed summary with [UB] to denote that the issue affects unbundled documentation. Comment by Scott Fordin [ 11/Feb/11 ] Will add topic to 3.1 Release Notes. Comment by Scott Fordin [ 25/Feb/11 ] Believe this was added to 3.1 Security Guide. Comment by Scott Fordin [ 25/Mar/11 ] Actually, it was not added to the Security Guide, so I've added it to the 3.1 Release Notes, and added the "3_1-release-note-added" tag.

### [GLASSFISH-15441] [UB]org.osgi.framework.BundleException during shutdown after upgrade Created: 05/Jan/11  Updated: 24/Mar/11  Resolved: 03/Mar/11

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

 Type: Bug Priority: Major Reporter: adf59 Assignee: Scott Fordin Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Solaris 10 Sparc

 Attachments: server.log     upgrade.log     upgrade.log Tags: 3_1-release-note-added, 3_1-release-notes, 3_1-upgrade

 Description
 During asupgrade to upgrade a V2.1.1 developer profile with a deployed webapp I am seeing the following error from upgrade.log (full log added as attachment): asadmin: Error while starting bundle: file:/sun/glassfishv2.1.1/glassfish3/glassfish/modules/autostart/org.apache.felix.bundlerepository.jar: org.osgi.framework.BundleException: Cannot start bundle org.apache.felix.bundlerepository [244] because its start level is 1, which is greater than the framework's start level of 0. asadmin: org.osgi.framework.BundleException: Cannot start bundle org.apache.felix.bundlerepository [244] because its start level is 1, which is greater than the framework's start level of 0. asadmin: at org.apache.felix.framework.Felix.startBundle(Felix.java:1690) asadmin: at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922) asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1136) asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1122) asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1115) asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:433) asadmin: at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:241)

 Comments
 Comment by Tom Mueller [ 05/Jan/11 ] Bobby, can you please take a look at this to figure out where this belongs? Comment by Bobby Bissett [ 05/Jan/11 ] Art, Can you give me more info on this? What build are you trying, and is there any info about the app? Comment by Bobby Bissett [ 05/Jan/11 ] All the upgrade tests are passing – does the server still work after you see this? Comment by adf59 [ 05/Jan/11 ] Build tested was latest nightly glassfish bundle dated jan 5. The server starts up fine and the helloworld web app is reachable. I just happen to see this error during the asupgrade and filed the bug. I upgraded a developer profile with HelloWorldApp deployed. Comment by Bobby Bissett [ 05/Jan/11 ] It took me several tries to reproduce this, and now I can't reproduce again. I suspect that those warnings are always happening, but there is a timing issue with whether or not they're logged. Can you attach the server log also? Comment by adf59 [ 05/Jan/11 ] It happens consistently with me. I am on a Solaris 10 Sparc system. I am attaching the server.log. Comment by adf59 [ 05/Jan/11 ] server.log and upgrade.log attached. Comment by Bobby Bissett [ 05/Jan/11 ] I've had to go to the dev list about this one: http://java.net/projects/glassfish/lists/dev/archive/2011-01/message/38 Art, since this happens every time for you, can you start/stop the domain and see if you see the same error? Comment by Bobby Bissett [ 05/Jan/11 ] Since this happens during a shutdown, and doesn't affect startup or use of the app server after the upgrade, I'm downgrading this to a P4. But I'd still like to find out what it means and whether it needs to be fixed or documented. Comment by adf59 [ 05/Jan/11 ] A stop and start of server does not show anything unusual. Everything looked fine. It appears you see this during the upgrade. Comment by Bobby Bissett [ 13/Jan/11 ] Am moving this over to docs. I've been talking with Richard Hall about this, and there's a chance it could be fixed by Sahoo. When I get more information, I'll attach it here. If the situation stays the same, then we should document that in some cases users will see these errors at the end of an upgrade. It happens during shutdown of the server and doesn't affect anything else. I don't know if it's material for the upgrade guide, release notes, etc. Comment by Bobby Bissett [ 13/Jan/11 ] I've heard from Sahoo that the issue won't be fixed for 3.1. GLASSFISH-15519 captures the error messages and explanation. This issue affects the server whenever it's started with the --verbose flag. Because the --upgrade flag implies the --verbose flag, that's why we're seeing it at the end of upgrades. So this information may need to be documented somewhere more general than some upgrade-specific documentation. (Side note: these error messages have always been present, but only showed up recently due to logging changes.) Comment by Bobby Bissett [ 09/Feb/11 ] Changing summary from: asadmin error during asupgrade of a developer profile with deployed app to: org.osgi.framework.BundleException during shutdown after upgrade Comment by Scott Fordin [ 11/Feb/11 ] Not sure if this should go in the Release Notes or in the Upgrade Guide proper. Any opinions? Comment by Bobby Bissett [ 11/Feb/11 ] I guess the release notes make more sense. It doesn't always happen, which is good, so I'm hoping no one even sees it on nice, fast production systems. Comment by Scott Fordin [ 03/Mar/11 ] Added topic to 3.1 Release Notes. Comment by Scott Fordin [ 24/Mar/11 ] Added "3_1-release-note-added" tag.

### [GLASSFISH-15429] Modifying keyfile path in a newly created config does not properly list the users Created: 04/Jan/11  Updated: 19/Dec/16

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1_dev
Fix Version/s: future release

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

Issue Links:
 Dependency blocks GLASSFISH-15406 Unable to edit custom admin-realm in ... Closed
Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description
 1. asadmin copy-config default-config new-config 2. asadmin get new-config.security-service.auth-realm.admin-realm.property.file new-config.security-service.auth-realm.admin-realm.property.file=${com.sun.aas.instanceRoot} /config/admin-keyfile 3. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile Command set executed successfully. 4. file /tmp/v3/admin-keyfile is not currently created. 5. asadmin create-file-user --authrealmname admin-realm --target new-config test Enter the user password> Enter the user password again> Command create-file-user executed successfully. 6. cat /tmp/v3/admin-keyfile test; {SSHA256}mjyhJFWxU8xUnGMY5bt+ngwj3tf6v6yOTKB7DgGKJUu6Neky/GVOsQ==;asadmin user1;{SSHA256} rImtlHJuqi6AMSypIUyBdcs2CUEPQq3pIEHSEsndYQmhBl4ZBT+fJA==;user1 8. asadmin list-file-users --authrealmname admin-realm new-config user1 Command list-file-users executed successfully. The list-file-users needs to be fixed to list from /tmp/v3/admin-keyfile  Comments  Comment by kumarjayanti [ 04/Jan/11 ] Srini, Either there is no bug or you have not given me the complete set of steps. With the steps that you provided it is not clear how the user :"user1" is already present in the /tmp/v3/admin-keyfile. Also are you using the latest builds. Here are the steps that i executed and i see no problems 1.)$ ./asadmin start-domain Waiting for domain1 to start .......... Successfully started the domain : domain1 domain Location: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1 Log File: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1/logs/server.log Admin Port: 4848 Command start-domain executed successfully. 2.) $./asadmin copy-config default-config new-config Command copy-config executed successfully. 3)$ ./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile Command set executed successfully. 4) $mkdir /tmp/v3$ > /tmp/v3/admin-keyfile 5) $./asadmin create-file-user --authrealmname admin-realm --target new-config test Enter the user password> Enter the user password again> Command create-file-user executed successfully. 6)$ cat /tmp/v3/admin-keyfile test; {SSHA256} H0J8mMtMJp1BcPynsBqyDw8r0WWI30796BaFrsdmei3eBh3YDILKKg==;asadmin 7) $./asadmin list-file-users --authrealmname admin-realm new-config test Command list-file-users executed successfully. 8)$ ./asadmin create-file-user --authrealmname admin-realm --target new-config user1 Enter the user password> Enter the user password again> Command create-file-user executed successfully. 9) $./asadmin list-file-users --authrealmname admin-realm new-config test user1 Command list-file-users executed successfully. Comment by kumarjayanti [ 04/Jan/11 ] Cannot reproduce. Make sure you are using the very latest glassfish build. And please provide the exact steps to reproduce. I will try some other combination in the meantime to see if i can reproduce anything like what u mention. Comment by srinik76 [ 04/Jan/11 ] I have not created the file. As per the requirement do we need to create the file. If not created we see this problem. Comment by kumarjayanti [ 04/Jan/11 ] The Keyfile needs to be created physically and ideally this should be done before even the set command is executed to change the keyfile property. That said, if the keyfile is not created then when i test purely from CLI i do not get the problem you see. I see the create-file-user fails. Comment by Anissa Lam [ 04/Jan/11 ] It is the responsibility of the user to create the keyfile ( I hope the documentation specifies that) or the security code should be smart enough to detect that the keyfile doesn't exist and create that for the user. GUI should NOT create the keyfile. As commented in GLASSFISH-15406, there is error given if the keyfile doesn't exist.$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test Enter the user password> Enter the user password again> remote failure: Adding User test to file realm admin-realm failed. Command create-file-user failed. GUI should show the error to the user. However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear. Comment by srinik76 [ 04/Jan/11 ] Tested with the latest build, create-file-user fails with following message asadmin create-file-user --authrealmname admin-realm --target new-config test Enter the user password> Enter the user password again> remote failure: Adding User test to file realm admin-realm failed. /tmp/v3/admin-keyfile (No such file or directory) /tmp/v3/admin-keyfile (No such file or directory) list-file-users also should report that /tmp/v3/admin-keyfile is not found, but it lists the user (admin) asadmin list-file-users --authrealmname admin-realm new-config admin Command list-file-users executed successfully. Comment by kumarjayanti [ 05/Jan/11 ] Anissa Said : ---------- GUI should show the error to the user. However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear. -------- I checked the code and the CLI command tried to do the following : report.setMessage( localStrings.getLocalString("create.file.user.useraddfailed", "Adding User {0} to the file realm {1} failed", userName, authRealmName) + " " + localalizedErrorMsg); report.setActionExitCode(ActionReport.ExitCode.FAILURE); report.setFailureCause(e); It appears when the Message is set it takes priority over setFailureCause in the admin framework. I can remove the setMessage for the next release. Or if you think it is important for you since this message has to be displayed in the GUI then please reopen the bug and i will ask for approval. I see a similar problem with list-file-users as well where it sets all the 3 items on the report object and hence the message that was set takes priority and that message is currently not very good. I can fix both of them as part of this. The question is would you like messages fixed for V3.1. Comment by srinik76 [ 05/Jan/11 ] Reopening issue after discussing with kumar. Now from the security side it will check for the keyfile existence while listing file users. Comment by kumarjayanti [ 05/Jan/11 ] 1) How bad is its impact? (Severity) While we are unable to reproduce it by pure CLI operations it appears GUI seems to observe some incorrect file-user listing in this case. Also the message log for the Failure can be improved to indicate the real cause. 2) How often does it happen? (Frequency) This will occur only when keyfile of a file-realm points to a non-existent File. 3) How much effort is required to fix it? (Cost) Minor : the fix is to add a check for non-existent keyfile and throw an error. 4) What is the risk of fixing it? (Risk) None (does not affect the Runtime). GUI wants these enhancements. Comment by Anissa Lam [ 05/Jan/11 ] Approved. Comment by kumarjayanti [ 05/Jan/11 ] fixed Comment by srinik76 [ 05/Jan/11 ] Fix works fine, but when the key file is created list-file-users should report none, but lists admin user. Waiting for comments from kumar to reopen the issue. Comment by srinik76 [ 06/Jan/11 ] After changing the key file and restarting the server, it works fine. Comment by srinik76 [ 06/Jan/11 ] Comments from Kumar in email Hi Srini, Anissa, I think i understand what is happening. 1. default-config is copied as new-config 2. Now the admin-realm is selected in the GUI from this new-config 3. Its KeyFile property is changed to some XYZ and the change is saved. Using an asadmin set-command 4. A physical XYZ file is created 5. Now again ManageUsers is clicked on the admin-realm of new-config 5.1. At this time ListFileUsers command still shows the original admin user that is part of the admin-realm in default-config Is this a correct description of the issue ?. If that is true then yes that can happen. 1. Step 2 loads the admin-realm in the Backend. 2. Setp 3 modifies the property of the realm in the Config-Layer 3. Backend is not informed of this change. And since the new-config is not the running config of the Server (DAS) the ConfigListener Mechanism (which is in place) does not come into picture. So the backend realm is never updated. 4. ListFileUsers command which executes as part of step (5) above does a refresh of the keyfile contents but it never goes back to the config-layer to see if the keyfile has changed. And it does not make sense for ListFileUsers to do that (checking for changes to the realm definition in config-layer). Things would have worked if it did that but really the syncing between Config-Layer and Backend should have happened when step (3) above invoked the "asadmin set" command to modify the keyfile property. There are 4 solutions : 1. I can provide a new hidden command which has to be executed by GUI whenever they do a asadmin set on any realm (and file-realm in particular). This command would then try to sync the Config change made by the set to the backend. For some realms this inplace update cannot be performed for-example if it is an LDAPRealm of the active server config and there are applications currently using that realm and the set command tries to modify the URL of the LDAP server or the base-dn of the LDAPRealm. Such changes will require a RESTART of the Application Server. 2. Fix ListFileUsers to re-read the config-layer. Not a good idea and not the right fix. 3. GUI can indicate after the set-command that Appserver should be restarted. 4. GUI should not use an asadmin set to modify the keyfile location. Instead it should delete the existing Realm and create a New Realm with modified properties. Let me know which approach would be best for V3.1. regards, kumar Waiting for Anissa's comments to decide what approach (1 out of 4 suggested by kumar) to be taken for the solution. Anissa/Kumar, Can I reopen the bug? Comment by kumarjayanti [ 06/Jan/11 ] I am also not sure if a Property change in realm (using asadmin set) in an active server config will cause the Config Change Event which can be received by a registered ConfigListener. Comment by Anissa Lam [ 06/Jan/11 ] As i understand it, only GUI user sees this problem. CLI user will not have such an issue. Correct me if i am wrong. But i just tried using CLI to do all the steps and list-file-user reports the correct list. So, what exactly is missing in GUI code, compared to CLI, that causes this error in GUI only ? I want to understand this, and that maybe how we should fix it. The corresponding steps in CLI works perfectly fine, and list-file-user is reporting the list of users from the new key file correctly. ~ 1) asadmin copy-config default-config TEST-config Command copy-config executed successfully. ~ 2) ~ 2) asadmin list-file-users --authrealmname admin-realm server-config admin Command list-file-users executed successfully. ~ 3) ~ 3) ~ 3) asadmin get configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=${com.sun.aas.instanceRoot} /config/admin-keyfile Command get executed successfully. ~ 4) ~ 4) asadmin set configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile Command set executed successfully. ~ 5) ~ 5) ~ 5) touch /tmp/keyFile ~ 6) ~ 6) asadmin list-file-users --authrealmname admin-realm TEST-config Command list-file-users executed successfully. ~ 7) ~ 7) Comment by Anissa Lam [ 06/Jan/11 ] Re-open issue as this is still under active discussion and GUI depends on the fix. Comment by kumarjayanti [ 06/Jan/11 ] Your step two : ~ 2) asadmin list-file-users --authrealmname admin-realm server-config should be changed to 2) asadmin list-file-users --authrealmname admin-realm TEST-config and IMO that will reproduce the problem in CLI Comment by kumarjayanti [ 06/Jan/11 ] I retested after implementing solution 1. Here is the output :$ ./asadmin start-domain Waiting for domain1 to start .......... Successfully started the domain : domain1 domain Location: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1 Log File: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1/logs/server.log Admin Port: 4848 Command start-domain executed successfully. $./asadmin copy-config default-config new-config Command copy-config executed successfully.$ ./asadmin list-file-users --authrealmname admin-realm new-config admin Command list-file-users executed successfully. $./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile Command set executed successfully.$ ./asadmin __synchronize-realm-from-config --realmname admin-realm new-config Synchronization of Realm admin-realm from Configuration Successful. Command __synchronize-realm-from-config executed successfully. $./asadmin list-file-users --authrealmname admin-realm new-config Command list-file-users executed successfully.$ cat /tmp/mykeyfile $./asadmin create-file-user --authrealmname admin-realm --target new-config test Enter the user password> Enter the user password again> Command create-file-user executed successfully.$ ./asadmin list-file-users --authrealmname admin-realm new-config test Command list-file-users executed successfully. Comment by kumarjayanti [ 06/Jan/11 ] The new hidden command will set RESTART required if the change was done to an active server config $./asadmin set server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile Command set executed successfully.$ ./asadmin __synchronize-realm-from-config --realmname file server-config Restart required for configuration updates to active server realm: file. Command __synchronize-realm-from-config executed successfully. And here is how the code in the command sets the information required for GUI for a restart. I picked up this code from : core/kernel/src/main/java/com/sun/enterprise/v3/admin/GetRestartRequiredCommand.java private void setRestartRequired(ActionReport report) { report.setActionExitCode(ActionReport.ExitCode.SUCCESS); ActionReport.MessagePart mp = report.getTopMessagePart(); Properties extraProperties = new Properties(); Map entity = new HashMap(); mp.setMessage(_localStrings.getLocalString("RESTART_REQUIRED", "Restart required for configuration updates to active server realm: {0} .", new Object[] {realmName} )); entity.put("restartRequired","true"); extraProperties.put("entity", entity); ((ActionReport) report).setExtraProperties(extraProperties); } Comment by kumarjayanti [ 06/Jan/11 ] checked in the Partial Fix which will make the GUI work. GUI has to invoke the new hidden command whenever an asadmin set is invoked on any realm. The CLI this bug still remains if someone does the following sequence of operations : 1. asadmin copy-config default-config new-config 2. asadmin list-file-users --authrealmname admin-realm new-config admin Command list-file-users executed successfully. 3. asadmin get new-config.security-service.auth-realm.admin-realm.property.file new-config.security-service.auth-realm.admin-realm.property.file=${com.sun.aas.instanceRoot} /config/admin-keyfile 4. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile Command set executed successfully. 5. create the physical keyfile at /tmp/v3/admin-keyfile After doing these steps, the following command will give a wrong answer : 1. asadmin list-file-users --authrealmname admin-realm new-config admin Command list-file-users executed successfully. This is because the asadmin set command in step-4 above updates the Configuration Layer but does not update the Backend Realm which was loaded while executing step 2. So the list command will continue to list the user admin which was present in the original realm's keyfile (one that it was referring to before the set command changed it). Summary of the CLI Bug : If an asadmin set command is executed to change a realm-property for a realm that was loaded by the backend (due to an earlier CLI command targeted at the realm) , then the realm continues to behave as if the set command was not executed. The workaround is to restart Appserver after a set command has been used to change a property of an already loaded realm. Comment by Scott Fordin [ 15/Apr/11 ] Issue added to 3.1 Release Notes. ### [GLASSFISH-15424] [BigApps] [STRESS] ~17 occurences of "EOFException" warnings coming from JMS Created: 03/Jan/11 Updated: 19/Dec/16 Due: 18/Jan/11 Status: Reopened Project: glassfish Component/s: jms Affects Version/s: 3.1_dev Fix Version/s: 4.1.1  Type: Bug Priority: Major Reporter: varunrupela Assignee: Nigel Deakin Resolution: Unresolved Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Attachments: eof-issue.log server.log-instance101-24x1-gf-b37 Issue Links:  Dependency blocks GLASSFISH-15423 [STRESS] [BigApps] [Umbrella-Issue] 2... Closed Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1_1-scrubbed, 3_1_2-exclude, 3_1_2-release-note-added, 3_1_2-release-notes  Description  See parent issue 15423 for details of the BigApps run that causes this issue to appear in the server logs. A server log that shows the issue has been attached.  Comments  Comment by Satish Kumar [ 04/Jan/11 ] This is a bug in MQ. See http://java.net/jira/browse/MQ-72 for the corresponding MQ issue. Amy Kang is currently working on it and based on her feedback, a fix for this issue will be a part of the next MQ integration ... Comment by varunrupela [ 04/Jan/11 ] Satish, This is a different issue from the MQ-72 issue. The log is attached to the issue. We need to check on the cause for the log. Comment by Satish Kumar [ 04/Jan/11 ] As I had mentioned in my earlier comment, I suspect this issue may be caused due to http://java.net/jira/browse/MQ-72. Lowering the priority of this issue to Minor as discussed with Varun. We will need to have a re-look at this once MQ-72 is fixed and then decide if any further action is required here or if we can close this issue. Comment by Satish Kumar [ 05/Jan/11 ] Bumping-up the priority to Major based on Nazrul's feedback. We plan to leave this issue open until the fix for MQ 72 has been integrated and the stress tests have been run again and observe if the exceptions are reappearing in the new test run. Comment by Nazrul [ 10/Jan/11 ] Please confirm if MQ-72 resolved this problem. Comment by varunrupela [ 12/Jan/11 ] The issue continues to exist in build 37. Comment by varunrupela [ 13/Jan/11 ] Added one of the instance's server log after a 24x1 run of the same scenario. Comment by Satish Kumar [ 13/Jan/11 ] Assigning this issue to Nigel as per our discussion this evening... Comment by Nigel Deakin [ 14/Jan/11 ] These messages [#|2011-01-13T11:14:06.600+0530|WARNING|glassfish3.1|javax.jms|_ThreadID=29;_ThreadName=Thread-1;|[I500]: Caught JVM Exception: java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes.|#] are warning messages. No errors or other messages were seen and there are no reports of the application behaving unexpectedly other than these messages. Other users have reported receiving these messages periodically in earlier versions of MQ. There is a discussion here: http://markmail.org/message/hh2ejjuxp5mo6njp#query:+page:1+mid:rumu3mg7unqbgm25+state:results to which MQ team members responded. This warning message is logged by the MQ client thread that is reading messages from a socket connected to the broker. (Note that even though the broker is embedded, since the broker is clustered, the client uses TCP to connect to the broker). The exception suggests that the client had received a "zero-length packet" from the broker. This message is often seen when the broker has failed, though this is not the case here. In that email discussion the MQ technical lead speculates that it is "probably a side effect of destination limits or TTL" and suggests that if there are no other problems the messages can be ignored. Note that after this exception has been logged the client will attempt to recover the connection and carry on. This appears to have been the case here since no further messages were logged. This is just a warning message, and is logged as such. Arguably GlassFish should never log warnings, but to suppress it might cause useful information to be lost if there are other problems. So it is proposed to close this bug as "not being a bug". Comment by varunrupela [ 17/Jan/11 ] Based on the analysis, the issue can be waived for GF 3.1. The issue should remain open as it appears in GF build 37 and as the MQ team will fix it in the long-term. It is useful to keep this issue open as opposed to creating a new one, since it contains quite some information around the bug. Comment by Nigel Deakin [ 17/Jan/11 ] Adding 3_1-exclude 3_1-release-notes tags. Note that this issue now only concerns the EOFExceptions and no other messages. The release note should mention that very occasionally WARNING messages "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" may be observed in the server log. If no other messages or exceptions are logged at the same time in either the server or broker logs these messages may be ignored. Comment by varunrupela [ 18/Jan/11 ] set the target release Comment by easarina [ 18/Jan/11 ] Was used b38 01/14. richAccess + SSL stress test on Win 2008 machines. Saw multiple "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" warnings in server.log files. Was used jdk 1.6.0_23, 64 bit. Comment by Nigel Deakin [ 19/Jan/11 ] Updated summary to make it clear that it relates to warning messages, not exceptions. Comment by Scott Fordin [ 23/Mar/11 ] Need more info to add issue to 3.1 Release Notes. Is a release note still necessary? Comment by Nigel Deakin [ 25/Mar/11 ] Please add the following text (which I gave in my comment on 17 Jan) to the release note: Issue 15424: Very occasionally WARNING messages "java.io.EOFException: Trying to read 72 bytes. Already read 0 bytes" may be observed in the server log. If no other messages or exceptions are logged at the same time in either the server or broker logs these messages may be ignored. Nigel Comment by Scott Fordin [ 15/Apr/11 ] Added issue to 3.1 Release Notes. Comment by Nigel Deakin [ 14/Dec/11 ] Excluding from 3.1.2 for the same reason it was excluded from 3.1.1. It should continue to be mentioned in the release note. Comment by Rebecca Parks [ 24/Jan/12 ] If it's in the 3.1.1 Release Notes, it's carried over to 3.1.2 unless it's fixed in 3.1.2. There's no need to flag it for 3.1.2. Comment by Nigel Deakin [ 15/Feb/13 ] In accordance with the project triage guidelines this is not needed for 4.0 and so has been deferred until 4.0.1. Setting "fix version" accordingly. ### [GLASSFISH-14547] Mysql ping fails when additional properties are not deleted Created: 09/Nov/10 Updated: 24/Feb/12 Status: Open Project: glassfish Component/s: jdbc Affects Version/s: 3.1 Fix Version/s: None  Type: Improvement Priority: Major Reporter: shaline Assignee: Shalini Resolution: Unresolved Votes: 2 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Operating System: All Platform: All  Attachments: domain.xml Issuezilla Id: 14,547 Tags: 3_1-release-note-added, 3_1-release-notes  Description  Build used: GFV3.1 nightly dated: 11/7 OS: Windows XP Browser: IE8 When we keep all the additional properties for the Mysql pool ,and the values for user, password and url fields, the ping fails. When we delete these additional properties and keep only the User,Password and url properies, the ping succeeds. steps: Copy mysql-connector-java-5.1.7-bin.jar to domain1/lib/ext and restart. Create a JDBC connection pool as below: datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" res-type="javax.sql.DataSource" name="MyPool"> "url" value="jdbc:mysql://asqe-core2.sfbay.sun.com:3306/dbsmpl1" "Password" value="dbpassword" "User" value="dbuser" Keep all the additional properties intact, and try Ping. it fails. delete them and try ping again, it succeeds.  Comments  Comment by Anissa Lam [ 09/Nov/10 ] Can you let us know what are the additional props and its value when the ping failed for you ? If you do the ping through CLI, doees it work for you ? Comment by shaline [ 09/Nov/10 ] Created an attachment (id=5387) domain.xml Comment by Anissa Lam [ 09/Nov/10 ] thanks for domain.xml. Can you ping successfully using CLI ? Comment by shaline [ 09/Nov/10 ] ping fails even in CLI since the additional properties are added from admin console. If we remove the additional properties , then ping succeeds even in console,and CLI. Comment by Anissa Lam [ 10/Nov/10 ] those properties are whats given to us from backend. transferring to 'jdbc' for evaluation. Comment by sumasri [ 11/Nov/10 ] Transferring it to backend team. Comment by Jagadish [ 11/Nov/10 ] This behavior has been there since Application Server 8.x Please refer issue 549 , there was a detailed discussion about MySQL driver exposing all these attributes. GlassFish will not have a control over these properties. The only option we had was to make GUI show the standard properties and then in another tab showing all properties. StandardProperties = { "databaseName", "serverName", "port", "networkProtocol", "user", "password", "roleName", "datasourceName" } ; Marking this as RFE. As long as the user follows the documented list of properties (docs of GlassFish), it works fine. http://docs.sun.com/app/docs/doc/820-7692/gbsor?l=en&a=view Anissa, let me know if its possible to change admin console screen to show standard properties first (atleast for MySQL case alone) and then based on the request from user, show all other properties, I can work on providing an API which can be called by console. Also refer the issue 3475 (enhancement) Comment by Anissa Lam [ 11/Nov/10 ] Its too late now to make this kind of UI change. We can think about this after 3.1 thanks. Comment by Scott Fordin [ 23/Mar/11 ] Need more info to add issue to 3.1 Release Notes. Comment by Shalini [ 23/Mar/11 ] When a ping is done with all the properties mentioned in the domain.xml(attached) for mysql-pool, the following error message is got. Ping failed Exception - Access denied to execute this method : setLargeRowSizeThreshold Please check the server.log for more details. Workaround is to provide only the standard list of properties documented. The standard properties are "databaseName", "serverName", "port", "networkProtocol", "user", "password", "roleName", "datasourceName". Comment by Scott Fordin [ 15/Apr/11 ] Added issue to 3.1 Release Notes. Comment by Shalini [ 25/Apr/11 ] This is an RFE and could be addressed in 3.2. The solution for this is tricky as in, if only the standard properties are listed for all jdbc drivers, the user would have to look into the jdbc driver vendor documentation for the available properties and set each one of them by typing it manually. Its much easier to delete the properties that cause a failure before trying a ping rather than adding lot of properties manually. Comment by Nazrul [ 24/Feb/12 ] Configuring a MySQL pool needs just these 6 properties, may be even a few less. Currently, we show a long list of properties. It would be good if we can show standard properties for all JDBC drivers to make user experience better. We may display the entire set of properties introspected from JDBC driver in advanced tab. ### [GLASSFISH-13873] If TS resource had been changed, tables are not created after server restart Created: 07/Oct/10 Updated: 15/Apr/11 Status: Open Project: glassfish Component/s: ejb_container Affects Version/s: 3.1 Fix Version/s: future release  Type: Bug Priority: Major Reporter: easarina Assignee: marina vatkina Resolution: Unresolved Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Operating System: All Platform: All  Attachments: server.log timersession.ear Issuezilla Id: 13,873 Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes  Description  Build 23 10/07. Solaris 10 Sparc. Installed thid build on one machine. Created a cluster with two instances. Then started a cluster. After that executed: #!/usr/bin/perl require "./conf.pl";$out=$S1AS_HOME/bin/asadmin start-database; print$out; $out=$S1AS_HOME/bin/asadmin stop-cluster c1; print $out;$out=$S1AS_HOME/bin/asadmin set configs.config.c1-config.ejb-container.ejb-timer-service.timer-datasource=jdbc/__default; print$out; $out=$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default; print $out;$out=$S1AS_HOME/bin/asadmin start-cluster c1; print$out; $out=$S1AS_HOME/bin/asadmin list-instances; print $out;$out=$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear; print$out; $out=$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client ./timersessionClient.jar; print $out; ================================================================ The appclient was executed successfully. Then I've reinstalled everything and executed such sequence of the commands: =================================================== #!/usr/bin/perl require "./conf.pl";$out=$S1AS_HOME/bin/asadmin start-database; print$out; $out=$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear; print $out;$out=$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client ./timersessionClient.jar; print$out; $out=$S1AS_HOME/bin/asadmin undeploy --target c1 timersession; print $out;$out=$S1AS_HOME/bin/asadmin stop-cluster c1; print$out; $out=$S1AS_HOME/bin/asadmin set configs.config.c1-config.ejb-container.ejb-timer-service.timer-datasource=jdbc/__default; print $out;$out=$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default; print$out; $out=$S1AS_HOME/bin/asadmin start-cluster c1; print $out;$out=$S1AS_HOME/bin/asadmin list-instances; print$out; $out=$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear; print $out;$out=$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client ./timersessionClient.jar; print$out; ================================================ In this case not only seconf execution of the appclient totally failed, but also second deployment failed. I believe, if once TS did not start successfully and it is not running, then during next invoke, has be to cleaned everything and TS should be started again. I've restarted cluster, db, domain, tried to undeploy an app and deploy it again, but it did not help. So only a full uninstall helps to clean everything. I've attached timersession.ear and in1 server.log.

 Comments
 Comment by easarina [ 07/Oct/10 ] Created an attachment (id=5096) timersession.ear Comment by easarina [ 07/Oct/10 ] Created an attachment (id=5097) in1 server.log Comment by marina vatkina [ 07/Oct/10 ] As this would be something we didn't provide before, making it an RFE for the next release. Comment by easarina [ 07/Oct/10 ] I believe, that for this release has to be provided at least a work around. I.e. if first time TS did not start, how to clean everything and make it start next time without reinstalling the glassfish. Comment by marina vatkina [ 07/Oct/10 ] You need to restart the DAS as well Comment by easarina [ 07/Oct/10 ] As I've wrote I've restarted DAS, cluster, DB. But it did not help. Comment by marina vatkina [ 08/Oct/10 ] This is what's going on: The 1st time you started, TS was (absolutely fine) deployed to jdbc/__TimerPool, so after restart, even though the code figured out that it's a different resource, the file marker left behind said it's a load, not a deploy. May be the file should contain the last (all?) resources TS was deployed to... Comment by easarina [ 08/Oct/10 ] When was added glassfish3/glassfish/domains/domain1/generated/ejb-timer-service- app, the second deployment/appclient execution were OK. I.e. such sequence of commands worked: =================================================== #!/usr/bin/perl require "./conf.pl"; $out=$S1AS_HOME/bin/asadmin start-database; print $out;$out=$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear; print$out; $out=$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client ./timersessionClient.jar; print $out;$out=$S1AS_HOME/bin/asadmin undeploy --target c1 timersession; print$out; $out=rm -rf$S1AS_HOME/domains/domain1/generated/ejb-timer-service-app; print $out;$out=$S1AS_HOME/bin/asadmin stop-cluster c1; print$out; $out=$S1AS_HOME/bin/asadmin stop-domain; print $out;$out=$S1AS_HOME/bin/asadmin start-domain; print$out; $out=$S1AS_HOME/bin/asadmin set configs.config.c1-config.ejb-container.ejb-timer-service.timer- datasource=jdbc/__default; print $out;$out=$S1AS_HOME/bin/asadmin create-resource-ref --target c1 jdbc/__default; print$out; $out=$S1AS_HOME/bin/asadmin start-cluster c1; print $out;$out=$S1AS_HOME/bin/asadmin list-instances; print$out; $out=$S1AS_HOME/bin/asadmin deploy --target c1 --retrieve . ./timersession.ear; print $out;$out=$S1AS_HOME/bin/appclient -targetserver localhost:13700 -client ./timersessionClient.jar; print$out; ======================================================== But it doesn't work without stop-domain/start-domain. I believe this sequence of the commands has to work without a domain restating. Comment by marina vatkina [ 17/Nov/10 ] Let's RN for this release that if the EJB Timer resource was changed after the EJB Timer Service was started on a previous resource, a) DAS needs to be restarted if any automatic timers are to be deployed, and b) unless the EJB Timer table is created manually, the marker file glassfish3/glassfish/domains/domain1/generated/ejb-timer-service-app needs to be removed as well. Please reassign it back to ejb-container after it is documented Comment by Paul Davies [ 17/Nov/10 ] Added 3.1-release-notes keyword to ensure that this issue is documented in the RN and reset the subcomponent and owner. Comment by Scott Fordin [ 15/Apr/11 ] Added issue to 3.1 Release Notes.

### [GLASSFISH-13774] Win. Deployment with contextroot: Application [] contains no valid components Created: 03/Oct/10  Updated: 20/Dec/16  Resolved: 11/Mar/11

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

 Type: Bug Priority: Major Reporter: easarina Assignee: Tim Quinn Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Operating System: All Platform: All

Attachments: bookstore.war     derby.bookstore.sql     server.log
Issue Links:
 Duplicate is duplicated by GLASSFISH-13773 Win. Deployment with contextroot: The... Resolved Related is related to GLASSFISH-17094 deployment of war files packaged in e... Resolved
Issuezilla Id: 13,774
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description
 Promoted b22, Win7 machine. On this machine was created a cluster with two instances. The deployment with contextroot to the cluster, i.e.: asadmin deploy --target --contextroot temp --name qwerty1, failed for several apps with such messages (see bellow). The same command did not create any issues on Mac, Linux, Solaris. I've attached an app. ===================================================================== DEPLOY WITH CONTEXT bookstore [#|2010-10-03T16:33:07.208- 0700|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.serv er|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app [qwerty1]|#] [#|2010-10-03T16:33:07.212- 0700|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deplo yment.admin|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app [qwerty1] : Application [] contains no valid components|#] ===========================================================

 Comments
Comment by Hong Zhang [ 03/Oct/10 ]

I don't see the attached app, is it the same one as in issue 13773?

Tim: can you take a look at this as it only happens on windows? Thanks!

Comment by easarina [ 03/Oct/10 ]

For this app were created such resources:

$S1AS_HOME/bin/asadmin create-jdbc-connection-pool --target$CLUSTER --property
User=BOOKSTORE:Password=BOOKSTORE:dataBaseN
ame=DerbyDB:serverName=localhost:portNumber=1527 --restype javax.sql.DataSource
--datasourceclassname org.apache.derby.jdbc
.ClientDataSource bookstorePool
$S1AS_HOME/bin/asadmin create-jdbc-resource --target$CLUSTER --connectionpoolid
bookstore-pool jdbc/BookDB

Comment by easarina [ 03/Oct/10 ]

Created an attachment (id=5054)
bookstore.war

Comment by easarina [ 03/Oct/10 ]

Created an attachment (id=5055)
derby.bookstore.sql

Comment by Tim Quinn [ 04/Oct/10 ]

Hi, Elena.

Do you happen to know if this happens on Windows XP also? That's the type of
Windows system I have access to.

I will try it myself soon; I just wondered if you already knew. Thanks.

Comment by Tim Quinn [ 04/Oct/10 ]

Setting expected target milestone to MS 7.

Comment by easarina [ 04/Oct/10 ]

I've reproduced this issue on XP machine.

Comment by easarina [ 26/Oct/10 ]

Re-run the test on Win7 against b25 10/25. Did not see this issue.

Comment by easarina [ 28/Oct/10 ]

Did not see this issue for b26

Comment by easarina [ 18/Nov/10 ]

Run the same test on Win 2008 machine. (I have two Win 2008 machines). I've run
the test at least 10 times, using b30. For both machines just one time this
exception was not seen. In all other cases. This exection wax seen for:

1) SingletonCMT

org.glassfish.api.admin.CommandException: remote failure: Error occurred during
deployment: Exception while deploying the app [qwerty1] : Application []
contains no valid components. Please see server.log for more details.
Command deploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application with name
[qwerty1] is not deployed
Command redeploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application qwerty1
is not deployed on this target [my-c1]
Command undeploy failed.

2) bookstore

org.glassfish.api.admin.CommandException: remote failure: Error occurred during
deployment: Exception while deploying the app [qwerty1] : Application []
contains no valid components. Please see server.log for more details.
Command deploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application with name
[qwerty1] is not deployed
Command redeploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application qwerty1
is not deployed on this target [my-c1]
Command undeploy failed.

3) SLSBNICMT
org.glassfish.api.admin.CommandException: remote failure: Error occurred during
deployment: Exception while deploying the app [qwerty1] : Application []
contains no valid components. Please see server.log for more details.
Command deploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application with name
[qwerty1] is not deployed
Command redeploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application qwerty1
is not deployed on this target [my-c1]
Command undeploy failed.

See, for example, hudson job:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/49/

Comment by easarina [ 01/Dec/10 ]

I've run a deployment test against nightly build 31 11/30 on Win 2008 machine. See the results of the run under:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/56/artifact/appserver-sqe/reports/pe-pe/amd64_JED-ASQE-21_Windows_NT/html/summaryreport.html

The deployment of several apps:
SLSBNICMT
SingletonCMT
bookstore

failed with this message.

Comment by Tim Quinn [ 03/Dec/10 ]

This is some of the server.log output Elena sent to us (thanks, Elena).

[#|2010-11-30T19:34:47.639-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Exception while deploying the app [qwerty1]|#]

[#|2010-11-30T19:34:47.639-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Application [] contains no valid components
java.lang.IllegalArgumentException: Application [] contains no valid components
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:77)
at com.sun.enterprise.deployment.Application.visit(Application.java:1764)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:794)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:273)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.open(ApplicationArchivist.java:228)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.open(ApplicationArchivist.java:80)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:179)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:92)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:825)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:767)
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:369)
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:1061) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1257) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1246)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:449)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:216)
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:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

 #]

[#|2010-11-30T19:34:47.643-0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=17;_ThreadName=Thread-1;|Exception while deploying the app [qwerty1] : Application [] contains no valid components|#]

Comment by Tim Quinn [ 03/Dec/10 ]

Using an up-to-date workspace I have been working with a Windows 7 system. I have not yet been able to reproduce the problem. It might be because I am using a fast system that does not show the race condition Elena has encountered. Still looking.

Comment by Tim Quinn [ 03/Dec/10 ]

I think part of the reason I might not see the same error is that the provisioned system I am using to test is virtual with a single virtual CPU.

Considering this is a race condition it might appear only in a multi-CPU/multi-core environment.

Elena, is your testing on a multi-CPU/multi-core system?

Comment by easarina [ 03/Dec/10 ]

The last time I saw this issue on such Win 2008 machine
Processor: AMD Opteron (tm) Processor 154 2.80 GHz
RAM 2.00 GB
System Type: 64-bit OS.

I saw this issue during hudson runs, I'm not sure that it is easy to reproduce this issue manually.

Comment by Hong Zhang [ 06/Dec/10 ]

I could not reproduce the problem with bookstore.war on the windows machine where we reproduced issue 13775.

As you said, this problem might only happen during hudson runs. It will be very hard to look into the problem if we can only reproduce the problem with running the whole test suite. It will be great if you can narrow it down to a small set of the steps for us to look into it.

One question, during the hudson run where this is reproducible, after the whole test suite finished (I assume all applications will be undeployed at that point), what's left behind in the domains/domain1/applications directory?

Also you mentioned two other applications also having this problem:
SLSBNICMT and SingletonCMT. Can you attach the archives for them? Want to see if we have any luck reproduce the problem with these other two applications.

Comment by easarina [ 07/Dec/10 ]

I've tried to narrow the issue. I've run the tests many times with a small subsets of the archives on Win 2008 against latest b31 and b32. I was able to reproduce the issue one time, please see:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/66/

In this run also was presented an issue http://java.net/jira/browse/GLASSFISH-13773, it happened with table-generatorApp.

All archives, that were used in this run, can be checked out from appserver-sqe/pe/deployment_v3/archives

Comment by easarina [ 07/Dec/10 ]

I've reproduced the issue one more time with the same small set of apps on another Win 2008 machine, please see:
http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/77/

Again along with bug http://java.net/jira/browse/GLASSFISH-13773.

Comment by easarina [ 08/Dec/10 ]

DAS server.log file from http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/78/ execution.

Comment by Tim Quinn [ 13/Dec/10 ]

Here is the underlying problem.

1. A deployment of (for example) RosterApp.ear using "--name qwerty1" leaves a locked JAR file here:

applications/qwerty1/RosterApp_war/WEB-INF/lib/RosterAppEjb.jar

2. A later deployment of another app (for example bookstore.war) also using "--name qwerty1" fails because the ArchivistFactory.getPrivateArchivistsFor(ReadableArchive) method (line 131) checks composite archivists first. Although there is no std or runtime DD for an EAR present in the expanded directory, the ApplicationArchivist.postHandles method sees the left-over RosterApp_war directory (which could not be deleted because of the locked JAR contained within) and concludes that the app is an EAR and so returns true.

Later on, the validation fails because this is not in fact an EAR.

Comment by Tim Quinn [ 13/Dec/10 ]

I have some changes in my workspace which resolve the immediate problem I've described earlier. The presence of unused "leftover" JARs in the applications/appName directory no longer confuses GlassFish about what kind of archive it really is.

Now that the code goes beyond that point different problems have emerged. For example, after deploying the embeddable-embeddedApp.ear, disabling it, and enabling it, an attempt to deploy it with --force=true fails with errors resolving persistence units. This is the result of some of the JARs in the applications/appName directory being locked.

I have in my workspace some further changes that seem to relieve that problem. But it is too late to run the necessary tests to make sure these changes would not break anything.

My feeling had been that the original problem might be one we could live with. It happens only on Windows and only if the user deploys different types of applications in succession using the same application name.

But this new problem I have discovered causes problems in a much more common case: redeployment of an EAR with persistence units (on Windows). We should consider this for milestone 8.

Comment by Tim Quinn [ 15/Dec/10 ]

I am marking this to be fixed in 3.2; I do not think it rises to meet the criteria for fixing in 3.1.

• Impacts product security (no)
• Represents a CTS failure (no)
• Is a regression of functionality or performance available in a prior release (no)
• Introduces an incompatibility (no)
• Likely to generate a customer support call (possible but relatively unlikely)
• Significantly impacts the operation of a primary release driver feature (no)
• An in-your-face issue that will touch the majority of users (no)

All of the following must occur to trigger this problem:

• OS is Windows.
• One (or more) JAR files in the expanded applications/appName directory are locked as part of deployment or accessing the application, so that the JAR(s) are not removed during undeployment.
• The same or another application is later deployed with the same name.
• The new application does not contain the previously-locked JAR file in the same location.
• Some code in GlassFish searches all JARs in the application for some reason (e.g., annotation detection, persistence unit searching, sniffer work to identify the type of application).

Elena's very good test case revealed this problem by reusing the same application name when deploying different apps of different types. Because JARs from the earlier app were locked and remained behind, this confused various parts of GlassFish in different ways.

I have a working fix in my workspace. I plan to check the changes in for 3.2 rather than 3.1 Several classes that are affected are ones that are used in many places in GlassFish (FileArchive, for one) and because the bug is relatively rare the risk outweighs the benefit for a 3.1 fix.

Comment by Tim Quinn [ 26/Jan/11 ]

Issue 15691 is a duplicate of this one, at least in some respects.

The general deployment changes will work around such problems, but I have reassigned 15691 to the web container team for them to look at for 3.2 to eliminate the underlying cause.

Comment by Tim Quinn [ 03/Feb/11 ]

Fix checked in (trunk).

Project: glassfish
Repository: svn
Revision: 44886
Author: tjquinn
Date: 2011-02-04 00:10:13 UTC
Link:

Log Message:
------------
Fix for 13774

On Windows, deploy an EAR then undeploy it. (for example, stateless-session.ear from the devtests) Next, deploy a web app but use the same name as the just-undeployed EAR. (for example, webapps-caching.war from SQE) The undeploy of the EAR did not clean out the applications/appName directory because of a locked JAR. The deployment of the web app fails because GlassFish finds the "left-over" file and tries to treat it as part of the web app - which does not work.

These fixes change the FileArchive implementation so that it recognizes entries only if the entries are dated after a hidden timestamp maintained in the FileArchive's directory. This hides "left-over" files from a previous deployment that were not cleaned up.

Tests: error scenario in the issue on Windows, QL tests

Revisions:
----------
44886

Modified Paths:
---------------
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deploy/shared/FileArchive.java
trunk/v3/deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java
trunk/v3/deployment/common/src/main/java/org/glassfish/deployment/common/DeploymentUtils.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/server/ApplicationLifecycle.java
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchive.java
trunk/v3/deployment/common/src/test/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchiveTest.java
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/ApplicationArchivist.java

Comment by Tim Quinn [ 25/Feb/11 ]

One of the new unit tests failed for Jane on a Windows build.

testCreateWithOlderLeftoverEntryAndThenOpen(com.sun.enterprise.deploy.shared.FileArchiveTest)

Further, Amy reported problems with the web devtests on a Hudson system:
webtier-dev-tests-v3

So I am reopening this issue.

Comment by Tim Quinn [ 11/Mar/11 ]

Fix checked in.

Repository: svn
Revision: 45495
Author: tjquinn
Date: 2011-03-11 20:14:42 UTC
Link:

Log Message:
------------
Fix for 13774.

These changes implement a "stale" file handling mechanism for the FileArchive class which prevents stale files that were left over from a previous use of the same directory from being visible to a client of the FileArchive. This scenario would happen with some frequency on Windows when an app was deployed with a name, a JAR file remained open and so the expanded directory in applications/ could not be deleted, and a different app entirely was deployed using the same name. The applications/(appname) directory would be reused - since it remained from the previous app - and the stale file(s) within would confuse GlassFish. Now, such stale files are detected and are suppressed so they are not treated as part of the FileArchive.

A hidden file at the top level of the FileArchive directory records such stale files so even after a server restart the stale files are not visible.

pom change approved by Sahoo and Jane
Test: deployment devtests on Mac OS X and Windows; error scenario on both OS types; added unit tests

Revisions:
----------
45495

Modified Paths:
---------------
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deploy/shared/FileArchive.java
trunk/v3/deployment/common/src/main/resources/com/sun/logging/enterprise/system/tools/deployment/LogStrings.properties
trunk/v3/deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java
trunk/v3/deployment/common/pom.xml
trunk/v3/deployment/common/src/test/java/com/sun/enterprise/deploy/shared/FileArchiveTest.java
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommand.java
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/LocalStrings.properties
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/UndeployCommand.java
trunk/v3/deployment/common/src/main/java/org/glassfish/deployment/common/DeploymentUtils.java
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/ApplicationArchivist.java
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchive.java

Comment by Tim Quinn [ 14/Mar/11 ]

Release note info:

Summary:
On Windows under certain very specific conditions deploying the same or different applications using the same app name can result in unexpected errors.

To see this problem all of the following conditions must be true (from the Dec. 15 comment):

• User deploys an application with name appName.
• One (or more) JAR files in the expanded applications/appName directory are locked as part of deployment or accessing the application, so that the JAR(s) are not removed during undeployment.
• The same or another application is later deployed with the same name.
• The new application does not contain the previously-locked JAR file in the same location.
• Some code in GlassFish searches all JARs in the application for some reason (e.g., annotation detection, persistence unit searching, sniffer work to identify the type of application).

GlassFish will consider the left-over file to be part of the second application, even though it it is not. This can cause various errors, most notably "Application [] contains no valid components."

Workarounds: (again, relevant only on Windows)
1. Avoid deploying different applications using the same app name.
2. If you need to redeploy an application but have removed a file from the app and that file remains in the applications/appName directory tree even though you redeploy the app, consider deploying the revised app using a different app name.
3. If you see this error, restart the domain admin server (use the asadmin stop-domain command or stop the domain using the admin console) and then deploy or redeploy the app.

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.

### [GLASSFISH-13023] [UB]DOC. Describe how to setup a correct java on the remote machine Created: 18/Aug/10  Updated: 19/Dec/16  Resolved: 19/Apr/11

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

 Type: Bug Priority: Major Reporter: easarina Assignee: Scott Fordin Resolution: Fixed Votes: 0 Labels: None Remaining Estimate: 6 hours Time Spent: 30 minutes Original Estimate: Not Specified Environment: Operating System: Windows (generic) Platform: All

 Issuezilla Id: 13,023 Tags: 3_1-release-note-added, 3_1-release-notes

 Description
 Any remote asadmin command needs in java on the remote machine and such command use just a default java, if appserver was installed through unzipping an archive. Users have to be advised to execute from machine A: ssh java -version. And if it is not JDK 6, change it. For example, on Solaris and Linux recreate /usr/bin/java link pointing to the suitable java. Or by setting AS_JAVA pointing on the correrct java in config/asenv.conf on the remote machine Also I want to mention that usually /usr/bin/java is linked with jdk 4 or 5. So there will be error messages (for jdk4 a bad error message).

 Comments
 Comment by sherryshen [ 19/Aug/10 ] Thank Elena for filing this bug. Before jdk is configured as Elena described on Solaris 10 sparc machine, I saw the create-instance failure as below. [2010-08-18T00:58:15.96] # Actual: /export/hudson/workspace/sherry-clise1/glassfishv3/glassfish/bin/asadmin --user admin --host asqe-sb-7 --port 4848 create-node-ssh --nodehost asqe-sb-8 --installdir /export/hudson/workspace/sherry-clise2/glassfishv3/glassfish asqe-sb-8_agent [2010-08-18T00:58:15.96] [2010-08-18T00:58:20.70] Command create-node-ssh executed successfully. ...... [2010-08-18T00:58:32.86] # Actual: /export/hudson/workspace/sherry-clise1/glassfishv3/glassfish/bin/asadmin --user admin --host asqe-sb-7 --port 4848 create-instance --node asqe-sb-8_agent --systemproperties HTTP_LISTENER_PORT=46328:HTTP_SSL_LISTENER_PORT=46331:IIOP_LISTENER_PORT=46334:IIOP_SSL_LISTENER_PORT=46337:IIOP_SSL_MUTUALAUTH_PORT=46340:JMX_SYSTEM_CONNECTOR_PORT=46343 sa_server2 [2010-08-18T00:58:32.86] Command create-instance failed. [2010-08-18T00:58:39.04] remote failure: GlassFish requires Java SE version 6. Your JDK is version 5 [2010-08-18T00:58:39.04] Comment by Paul Davies [ 04/Oct/10 ] Added [UB] to Summary to denote unbundled documentation. Reassigned to sfordin as this information should probably be added to the Installation Guide or Release Notes. Comment by sherryshen [ 25/Oct/10 ] Issue 14115 has been marked as a duplicate of this issue. *** Comment by sherryshen [ 25/Oct/10 ] Issue 14115 has been marked as a duplicate of this issue. *** Comment by Scott Fordin [ 23/Mar/11 ] Can you please provide a clearer explanation of the issue and solution here? Comment by Scott Fordin [ 25/Mar/11 ] This seems to be pretty much a duplicate of http://java.net/jira/browse/GLASSFISH-13943. Specifically, we clearly state the JDK requirements, and we clearly tell users that there are a whole bunch of things that can go wrong if the user chooses to not use the right Java version, so I don't think we should be telling user how to not use the right version. Comment by sherryshen [ 30/Mar/11 ] After cluster is created and run, the error can occur at app runtime, JSP compile failure due to JRE in use on Win2008 +MKS9.2 in http://java.net/jira/browse/GLASSFISH-16271 The solution is to set AS_JAVA in asenv.conf. Comment by Scott Fordin [ 19/Apr/11 ] Added issue to 3.1 Release Notes. Comment by Scott Fordin [ 23/May/11 ] Restructured the Java Paths and Environment Settings section in the 3.1-3.1.1 Release Notes; divided it into several subsections that can be pointed to from other books. For example, I added pointer from the Installation Guide to this reworked section.

### [GLASSFISH-12264] [Release Note]Samples. at ant all output was seen URL for samples that don't have a web client Created: 15/Jun/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: sample_apps
Affects Version/s: v3.0.1
Fix Version/s: not determined

 Type: Bug Priority: Major Reporter: easarina Assignee: scatari Resolution: Unresolved Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified Environment: Operating System: Windows Vista Platform: All

 Issuezilla Id: 12,264 Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description
 OS: Solaris Sparc, build: SDK build 21. Samples. At the output from "ant all" for many apps that don't have a web client at all, for example criteriaQuery or hello-jaxws2.2, was seen URL under deploy-url- message. i.e. "Application deployed at htt://localhost:8080/... " I think that users should not see such misleading messages

 Comments
 Comment by scatari [ 11/Oct/10 ] The top level app-server-ant.xml that does the "deploy" of applications blindly calls this target that displays the message "Application deployed at ". The fix would be to display this message only when the sample has an accessible web client URL. This would require identifying such samples as part of the individual sample build system through setting a flag, something like "hasWebURL=true/false". Better yet do not display anything for now even for the applications that can be accessed through web. Anyhow, the URLs are part of the sample docs. Comment by scatari [ 11/Oct/10 ] Comment by scatari [ 12/Oct/10 ] This would need fix across samples, targeting for 3.2. Will have to Release Note considering the less impact on users, transferring to Doc. Scott, Please assign as appropriate. Comment by Paul Davies [ 13/Oct/10 ] Added 3.1-release-notes to indicate the issue should be documented in the Release Notes. Reset the subcomponent to sample_apps to enable any possible future code fix to be tracked. Comment by Paul Davies [ 13/Oct/10 ] Reassigned to owner of selected subcomponent. No need to assign it to the RN writer, as the 3.1-release-notes keyword indicates that this issue is to be documented in the RN. Comment by Nazrul [ 20/Dec/10 ] Will be release noted by documentation team. Excluding from 3.1 bug count. Comment by Scott Fordin [ 23/Mar/11 ] Need more info to add issue to 3.1 Release Notes. Comment by easarina [ 28/Mar/11 ] I did not try to run this test against latest builds. But the general idea, for apps that don't have a web client, users have to ignore this message and don't use the URL. Comment by Scott Fordin [ 13/Apr/11 ] Added issue to 3.1 Release Notes. 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.

### [GLASSFISH-3916] [UB]Resource Adapter call to XATeminator.recover hangs if automatic recovery is enabled Created: 13/Dec/07  Updated: 20/Dec/16  Resolved: 12/May/11

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

 Type: Bug Priority: Major Reporter: burdeasa Assignee: Rebecca Parks 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: 3,916 Status Whiteboard: v3_excluded Tags: 3_1-release-note-added, 3_1-release-notes

 Description
 I am the developer for a JCA 1.5 resource adapter named DTPRA. Note that DTPRA works with WebSphere Application Server, WebLogic Application Server and JBoss Application Server. I needed to test DTPRA with the Sun App Server, so I downloaded Sun Java System Application Server Enterprise Edition 9.1 (build b58g-fcs) to test DTPRA. I am now testing transaction recovery, so I set automatic recovery to true. That is, I have the following in my domain.xml: When I start the App Server with this setting, the App Server hangs and it never starts. Looking at trace output from DTPRA, it is clear that the following has happened: 1) The App Server called the ResourceAdapter.start method for DTPRA. 2) As part of DTPRA startup, DTPRA calls the App Server's XATerminator.recover method to see if there are inbound transactions to recover. The call to XATerminator.recover never returns. Apparently there is some sort of deadlock in the App Server when a resource adapter calls XATerminator.recover from the ResourceAdapter.start method. This only occurs when automatic recovery is enabled.

 Comments
 Comment by Sivakumar Thyagarajan [ 14/Dec/07 ] Thanks for filing this issue. Assigning to Jagadish to investigate further. Comment by Jagadish [ 09/Jan/08 ] assigning the issue to Sankar Comment by Jagadish [ 09/Jan/08 ] needs evaluation in jts module Comment by sankara [ 14/Feb/08 ] Present Architecture doesn't allow any transactional activity till the transaction recovery is completed and file based transaction logs are cleaned up. It will be a big change to support in current release and will be targeted for V3. Comment by marina vatkina [ 20/Jun/08 ] Reassign 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 marina vatkina [ 23/Sep/09 ] Post v3 Comment by marina vatkina [ 17/May/10 ] Will look into it... Comment by marina vatkina [ 04/Oct/10 ] With all the latest changes this seems to be fixed in 3.1. Please reopen if there is an exact scenario that causes any problems. Comment by Jagadish [ 27/Jan/11 ] After talking to Marina, re-opening and marking this issue for release-notes. " It is not advisable to do transactional activity (eg: starting a transaction / calling XATerminator.recover) during ResourceAdapter.start()). " Refer the original thread for more details : http://markmail.org/message/ogc7qndhaywfkdrp#query:+page:1+mid:kyyzpcexusbnv7ri+state:results Recently, we have encountered the following issue : http://java.net/jira/browse/GLASSFISH-15677 Though we propose to fix the above issue ( GLASSFISH-15677 ), there are other use-cases that might result in similar deadlock as stated in this issue ( GLASSFISH-3916). Comment by marina vatkina [ 27/Jan/11 ] We have 2 choices: a) RN it b) Document in 2 chapters - Transactions and Connectors - to get attention of all users Comment by Paul Davies [ 04/Mar/11 ] As this issue is included in the 3.1 Release Notes, the fix in the base documentation can be deferred until 3.2. Comment by Scott Fordin [ 15/Apr/11 ] Added topic to 3.1 Release Notes. Comment by Rebecca Parks [ 12/May/11 ] Added the Release Notes info to the Administration Guide's chapter on transactions, specifically the section on recovery limitations. Comment by scatari [ 06/Jun/11 ] Fixing the target version to include the correct build number.

Generated at Sat Apr 29 23:28:08 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.