GlassFish - World's first Java EE 7 Application Server


GlassFish v3 Upgrade

Goal

Seamless side-by-side upgrade from

Performing an upgrade

Given a source domain and a v3 target server, run the following. The -s param is optional (you can specify the source domain in the GUI), but it will save you a step. Assuming your domain is called 

domain1
:

<GFv3_root>/bin/asupgrade -s <source_gf>/domains/domain1

This will copy the source domain into the v3 domains directory, copy non-GlassFish jars from the source lib directory to the target lib directory, and then call 

asadmin start-domain --upgrade domain1
to perform the actual upgrade. If you already have a domain1 in the target server's domains directory, the tool rename it for you unless you cancel when prompted. Note: the original domain in the source server is untouched; it is copied over for you and the copy is upgraded.

For GF developers: If you're working on an upgrade service-related bug, it may be simpler for you to perform the upgrade without using the asupgrade tool. Copy the source domain (e.g., 'v2domain') into v3/domains and run:

java -jar modules/glassfish.jar -upgrade true -domain v2domain

This allows you to use 

-Xdebug
options when starting the server.

If you use javadb as your database

Remember that the database you use is separate from the application server. So if you use javadb and start it with 

asadmin start-database
without other options then by default your database library will be stored in gf_home/databases. If you do an upgrade from v2 to v3, your databases aren't copied over as well. So you can do one of these to make sure the application finds your tables:

  1. Use the original database with the new server. For instance: 
    gfv2_home/bin/asadmin start-database
    followed by 
    gfv3_home/bin/asadmin start-server
  2. Move the database information over to the new javadb instance you want to use. You can copy the folders from one gf_home/databases location to another. Databases created by javadb are portable across instances of javadb.
  3. Tell the v3 asadmin script where your databases are with the derby.system.home property. Use this option with asadmin to do so: 
    start-database --dbhome <path to db/log location>

In a production environment, the database information usually wouldn't be stored under your app server's installation directory, but since that's the default for development and testing, you may run into this issue working on upgrades. If you use NetBeans to start/stop javadb then you can edit the javadb properties to tell it which javadb installation to use and separately where to keep your databases. This is a good practice. See image.

Current issues

Link to v3 upgrade issues on java.net.

Dashboard

Module Owner Description Start Date End Date Status
Deployment Hong Zhang Transform applications and its sub-elements (Note: custom MBeans are going to be ignored and a log statement will be recorded in upgrade.log – Talk to km@dev.java.net if you need to know more) and redeploy the applications   08/24 Completed
Launcher Byron Nevins Handle changes to default values in java-config element August 21 August 24 Done – at least I remove the 5 jvm-options above and add the other 4. I can not get upgrade to work even if I do it manually though. V3 just hangs forever with prser errors.
Admin Kedar Mhaswade Handle changes to admin-service element, deprecation of auth-realm at jmx-connector     Backward compatibility handled in code. Both old and new configuration works. No need to upgrade
Security Service Kumar Jayanti Keystore and Truststore files 4/8 20/8 DONE: The files from the source domain need to be retained and this is happening by default.
Infrastructure Sahoo Handle changes to OSGI cache (Prelude to v3 only)     I don't expect any work in this area? Are you facing any issues? if so, let me know what they are and I shall look into them.
Web Container Jan Luehe Changes to default-web.xml     There is no work involved here. Upgraded web applications will inherit the latest default-web.xml contents during their redeployment. A virtual server's dummy web module will inherit the latest default-web.xml contents during server restart.
Logging Carla Mott Changes to log-service and its sub-elements, domain level logging attributes March 09 July 29 Done.
Monitoring Sreenivas Munnangi Changes to monitoring related configuration 18aug09 20aug09 Completed.
Security Kumar Jayanti Changes to security-service and its sub-elements, File realm files, Web Service Security configuration 4/8 20/8 DONE: All of the security-service from the source domain needs to be retained which happens by default. I have added a new SecurityUpgradeService which adds a new JACC provider configuration.
Grizzly Justin Lee Changes to http-service and its sub-elements   Jan/Feb 09 Completed and integrated
JBI Bhavani/Mohit Gupta Warn users about JBI no longer being available, offer to do upgrade of non-JBI content     For Service Engine, upgrade will be taken care by the GlassFish ESB. GlassFish upgrade tool need not do anything.
CMP Mitesh Meswani CMP remove depricated element persistence-manager-factory-resource from domain.xml. If a user's app was using the element from its sun-ejb-jar.xml, it needs to be changed to point to corresponding jdbc-resource element.   09/22 Completed
CMP Mitesh Meswani CMP has changed code gen from V2 to adapt to V3 changes     Applications are going to be redeployed. This would be taken care of as part of redeployment. No action required.
JPA Mitesh Meswani changed the default JPA provider from TopLink Essentials to EclipseLink. User's persistence.xml if referring to toplink.* properties would need to be changed to use eclipselink.* properties   In Progress Discussed this at today's (08/18) dev meeting. Jerome agreed that this upgrade may not be practical to implement. He directed to discuss this further at as-ccc. The discussion at as-ccc is in progress. <BR> Update from as-ccc meeting on (08/26). The translation of properties will be implemented inside EclipseLink. No work required on Upgrade side for this. Currently in discussion with EclipseLink team about details of the work. Expect to have an update on the discussion by 09/04
EJB Marina Vatkina EJB Timer service changes : only timer db schema changes (v2 Timer app will be removed by deployment code)   10/07 Completed
JDBC/Connector Shalini M, Jagadish Ramu Connection pool compatibility changes : Connection validation method and wrap jdbc objects default values are changed in v3.     No specific upgrade work is needed. V2's resources configuration will work fine in v3
CORBA/IIOP Ken Cavanaugh       No upgrade required. All legacy integration / version management is handled at runtime.
JMS (MQ) Ed Bratt / Linda Schneider       MQ performs its own upgrade and will not be invoked as part of this feature
JSF Ryan Lubke       No action necessary. JSF library is self-contained and has no domain specific requirements.

Related Documents

Usage scenarios

This page will keep track of all the use cases tested by the dev and sqe teams.

Working (Temporary) Documents

Issues related to simple upgrade of an empty v2.1 domain. The original version of this workaround is still on the manual upgrade notes page. This list reflects the status as of revision 31351

  1. FIXED: Was: "Remove the DTD from the beginning of the file." Issue 9127.
  2. FIXED: Was: "Remove all the elements under /domain/applications and resources"
  3. FIXED: Was: "Remove the following jvm-options element..." Issue 9531.
  4. FIXED: Was: "The following jvm-options should also be added..."
  5. FIXED: Was: "Remove the elements under thread-pools..." Issue 9530.
  6. FIXED: Was: "Add the following under admin-service element..." Issue 9529.

Attachments:
UpgradeTool_V3_TOI.pdf (application/pdf)
javadb_props.png (image/png)