[GLASSFISH-20403] stop standalone connectors after stopping all other applications during server shutdown Created: 24/Apr/13  Updated: 29/Apr/13  Resolved: 29/Apr/13

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

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

Tags: 4_0-approved


While evaluating issues GLASSFISH-20389 an GLASSFISH-20390
we found that standalone resource-adapters (connectors) are not stopped after stopping the other applications.

During server startup, while loading the applications, standalone connectors are started first and then other type of applications (war/ear/MDBs etc.,)
This is needed so that any application (war/ear/MDB) that is dependent on the standalone connector will work fine.

Similarly, the reverse must happen while stopping (shutting down) application server.

Comment by Jagadish [ 24/Apr/13 ]
  • What is the impact on the customer of the bug?
    While investigating GLASSFISH-20389 and GLASSFISH-20390, we found this issue. This might be seen
    randomly depending upon the order in which "applications" are registered in domain.xml.
  • How likely is it that a customer will see the bug and how serious is the bug?
    Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    What CTS failures are caused by this bug?
    This issue will be seen randomly. No CTS failures.
    This is a regression compared to GlassFish 2.x, exposed while debugging an issue related to Java EE 7 feature.
  • What is the cost/risk of fixing the bug?
    Fix is simple, to make sure that the standalone connectors are not stopped before stopping all other applications.

How risky is the fix? How much work is the fix? Is the fix complicated?
Fix is simple.
Fix is reviewed by Hong Zhang (Deployment)

  • Is there an impact on documentation or message strings?
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Deployment, Connector, EJB SQE Tests
    [I have verified Connector SQE tests]
    I have also verified that the following tests pass :
    QL (Web, Classic), deployment-dev, ejb-dev, connector-dev, jdbc-dev, connector-standalone-cts (Web, Classic), resources-admin-cli.
  • Which is the targeted build of 4.0 for this fix?
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
Comment by Tom Mueller [ 24/Apr/13 ]

Approved for 4.0.

Comment by Jagadish [ 29/Apr/13 ]

svn revision : 61635
Modified Paths:

Generated at Tue Dec 06 06:19:17 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.