This section describes the following new features in GlassFish Server 3.0.1:
Java EE 6 introduces the concept of profiles. A profile is a collection of Java EE technologies and APIs that address specific developer communities and application types.
The following profiles are implemented through the distributions of Oracle GlassFish Server 3.0.1:
Full Platform: The full Java EE platform is designed for developers who require the full set of Java EE APIs for enterprise application development, and is installed when you install Oracle GlassFish Server 3.0.1. This profile is also installed as part of the Java EE 6 SDK installation.
Web Profile: This profile contains web technologies that are a subset of the full Java platform, and is designed for developers who do not require the full set of Java EE APIs. This profile is also installed with Java EE 6 Web Profile SDK.
Java EE 6 SDK distributions are available from the Java EE 6 SDK downloads page.
For the list of APIs in each profile, see Java EE 6 Standards.
In GlassFish Server version 3.0.1, the GlassFish Server code was split into modules to provide flexibility and improved runtime performance. The modular architecture is implemented on top of OSGi Alliance standards and enables reusability of GlassFish Server 3.0.1 modules as well as other modules.
This design change allows use of only those modules that you require for the applications deployed. Runtime is used only for applications that use it, and upgrades can be implemented without a complete system reinstallation. This change minimizes startup times, memory consumption, and disk space requirements.
The modular design provides the ability to do the following:
Deploy OSGi bundles
Deploy library Java archive (JAR) files
Replace existing functionality with another implementation
A new Oracle GlassFish Server 3.0.1 container System Provider Interface (SPI) defines interfaces that a container developer must implement so that GlassFish Server can call into it at appropriate times. This change enables GlassFish Server users to customize GlassFish Server by adding administrative commands and graphical add-on components.
GlassFish Server also provides streamlined support of new module types, such as Ruby on Rails.
Update Tool is now embedded in the Oracle GlassFish Server 3.0.1 Administration Console. This tool facilitates managing add-on components and related applications that are available for extending GlassFish Server 3.0.1 functions.
The Administration Console provides access to the Update Tool page through the navigation tree. The Update Tool page provides tabs to display the following:
Components that are installed
Updates that are available for installed components
Add-on components that are available and can be installed
Integration of Update Tool in the Administration Console enables administrators to easily extend GlassFish Server and view available updates. A standalone version of Update Tool is also available using the updatetool command. For more information about Update Tool, see Update Tool in Oracle GlassFish Server 3.0.1 Administration Guide.
You cannot perform updates to existing components using the Update Tool interface directly from within the GlassFish Server Administration Console. To update or remove installed components, you must use the standalone command-line version or the pkg command.
Update Tool is developed through the Update Center project. The Administration Console uses the Update Center 2.3 API to display a list of available components, versions, and dates. For information about Update Center 2.3, see the Release Notes for Update Center 2.3 .
Update Tool differs from the older Upgrade Tool, which is used to migrate the configuration and deployed applications from an earlier version of GlassFish Server to the current version. For more information about Upgrade Tool, see the Oracle GlassFish Server 3.0.1 Upgrade Guide.
To facilitate rapid application development and deployment, Oracle GlassFish Server 3.0.1 supports a variety of scripting languages. The use of scripting languages enables GlassFish Server to be applied beyond developments that are centered on Java technology. Supported scripting languages include the following:
JRuby and Rails: A scripting language and a framework for developing web applications
Grails: A web application framework that leverages the Groovy programming language and complements Java web development
Jython and Django: A Java implementation of the Python language and a web framework for Python and implementations of Python (such as Jython)
jMaki: A framework for creating Ajax web applications
The components for integrating scripting languages with GlassFish Server are available through Update Tool.
Note that scripting languages are not covered under an Oracle GlassFish Server license and support offering.
Oracle is working closely with Microsoft to ensure interoperability of Web services enterprise technologies such as message optimization, reliable messaging, and security. WSIT is a product of this joint effort. WSIT is part of Metro 2.0, a high-performance, extensible web service stack that offers interoperability with Microsoft .NET 3.5. Metro 2.0 is included in the full distribution of GlassFish Server 3.0.1.
WSIT is an implementation of a number of open web services specifications to support enterprise features. In addition to message optimization, reliable messaging, and security, WSIT includes a bootstrapping and configuration technology. Starting with the core XML support currently built into the Java platform, WSIT uses or extends existing features and adds new support for interoperable web services, including:
Bootstrapping and Configuration
Message Optimization Technology
Reliable Messaging Technology
Security Technology
The appclient utility has been enhanced in GlassFish Server 3.0.1, as follows:
The appclient utility accepts an alternate command-line syntax that is similar to the syntax of the Java application launcher (java).
The -targetserver option is added to enable the server and port number of the target to be specified.
Splash screens in application clients are supported.
For more information, see the appclient(1M) man page.
Oracle GlassFish Server 3.0.1 uses EclipseLink as its Java Persistence API (JPA) 2.0 provider. EclipseLink is also the Reference Implementation for JSR 317. For the most recent information regarding EclipseLink functionality, see the EclipseLink 2.0 Release Notes.
In Oracle GlassFish Server 3.0.1, most HTTP Service settings have been moved into the new Network Service configuration. For more information, see the Oracle GlassFish Server 3.0.1 Upgrade Guide.
In Oracle GlassFish Server 3.0.1, you are not prompted for administration credentials by default. This is a change from previous releases.
If you install GlassFish Server using the ZIP file, you will not be prompted for administration credentials when you launch the Administration Console or use the asadmin utility and remote subcommands to perform administrative tasks.
If you install GlassFish Server 3.0.1 using the self-extracting file and graphical installer, you will not be prompted for administration credentials unless you specified a user name and password on the Administration Settings page during installation. If you accepted the defaults on that page, the default administrative user is admin and the password field is left empty.
If there is only one admin user with no password, unauthenticated logins are permitted. For more information about administrator authentication, see To Log In to a Domain in Oracle GlassFish Server 3.0.1 Administration Guide.
Administrator authentication requirements can be changed after GlassFish Server has been installed. For information about using the Administration Console to perform this and related tasks, see the Administration Console online help. For information about using the command-line interface, see Administering Passwords in Oracle GlassFish Server 3.0.1 Administration Guide.
The behavior of the asadmin utility has been modified to emphasize the distinction between options for the asadmin utility itself and options for its subcommands. Options for the asadmin utility itself are now allowed before the subcommand. However, for compatibility with other releases, options for the asadmin utility itself are still allowed after the subcommand, but such syntax is deprecated.
For more information, see Using the asadmin Utility in Oracle GlassFish Server 3.0.1 Administration Guide.
Oracle GlassFish Server 3.0.1 includes the following file layout changes from previous releases:
The default installation directories are as follows:
Solaris, Linux, and Mac OS X systems: user's-home-directory/glassfishv3
Windows systems: SystemDrive:\glassfishv3
A glassfish subdirectory has been added, with other subdirectories underneath.
Product libraries have moved from glassfish/lib to glassfish/modules.
An osgi directory has been added.
A designated directory for legal files has been added. License and copyright files are now in glassfish/legal.
Oracle GlassFish Message Queue is installed in a top-level directory instead of a subdirectory.
Java DB is installed in a top-level directory instead of a subdirectory.
Oracle GlassFish Server 3.0.1 provides server-specific Ant tasks, for which Ant must be installed. The asant utility is not included in the release.
GlassFish Server is compatible with Apache Ant versions 1.6.5 or greater. If Ant is not installed, you can install it using Update Tool.
For more information about Update Tool, see Update Tool in Oracle GlassFish Server 3.0.1 Administration Guide. For more information about Ant tasks, see Chapter 3, Using Ant with GlassFish Server, in Oracle GlassFish Server 3.0.1 Application Development Guide.
Because Oracle GlassFish Server 3.0.1 is modular and extensible, the domain.xml file cannot be validated against a static DTD file. Instead, the domain.xml file is validated against @Configured annotations in the source code. For more information about the structure of the domain.xml file, see the Oracle GlassFish Server 3.0.1 Domain File Format Reference.
Application-related differences exist between GlassFish Server 3.0.1 and GlassFish Server v2. This section describes some of those differences.
The default value of the force option for deployment is false in GlassFish Server 3.0.1. This default value was true in GlassFish Server v2. In GlassFish Server 3.0.1 you must explicitly set the option to true for redeployment. This option is not automatically set during the upgrade process. The purpose of this change is to avoid accidentally overwriting the contents of an existing application. This applies to both the Administration Console and command-line utility.
The asadmin redeploy command is also new in GlassFish Server 3.0.1 and offers an equivalent to --force=true. The force option is only applicable to the deploy command (command-line interface) and the deploy screen (console), not to the redeploy command and redeploy screen.
GlassFish Server v2 contained two subdirectories for the applications repository: applications/j2ee-apps and applications/j2ee-modules. Those subdirectories no longer exist in GlassFish Server 3.0.1 (there is no j2ee-apps or j2ee-modules level). Deployment of a standalone module such as foo.war, which was previously located in applications/j2ee-modules/foo in GlassFish Server v2, is now located in applications/foo in GlassFish Server 3.0.1. Enterprise applications and standalone modules essentially share the same name space, so the intermediate directory layer was not necessary.
Previous elements such as web-module, ejb-module, and so on are deprecated in GlassFish Server 3.0.1 and replaced with the new application element. For more information about the application element, see application in Oracle GlassFish Server 3.0.1 Domain File Format Reference.
During an upgrade, GlassFish Server v2 applications are redeployed at the new applications/ location with the new application element in domain.xml. Any new applications deployed on GlassFish Server 3.0.1 will be deployed with the new directory structure and element.
Java EE 6 imposes stricter JAR visibility rules than did Java EE 5. As a result, some older applications might fail.
The Java EE 6 specification imposes strict rules about which JAR files are visible from an enterprise archive (EAR) file. Refer to section EE.8.3.3; specifically, application client modules should not have access to any EJB JAR file unless the application client JAR file's manifest Class-Path refers to the EJB JAR file(s) explicitly.
This is a change from GlassFish Server v2, in which application clients automatically had access to all EJB JAR files in the EAR file and all JAR files at the top level of the EAR file. To comply with the stricter specification language, GlassFish Server 3.0.1 cannot automatically provide application clients with access to these JAR files.
This new, stricter behavior imposed by Java EE 6 can be addressed as follows:
If the application is deployed to a GlassFish Server v2 domain, Upgrade Tool will preserve the GlassFish Server v2 behavior for that application in that domain. For more information about upgrading, see Oracle GlassFish Server 3.0.1 Upgrade Guide.
Change the manifest Class-Path of the client so it refers explicitly to the JAR files on which it depends. The Class-Path must not list JAR files in the EAR file's library directory. As required by the specification, all JAR files in that directory are available to all modules in the EAR file. This directory is /lib by default, or can be set to some other directory using library-directory in the application.xml descriptor.
Deploy the EAR file using the optional --property compatibility=v2 setting. This preserves the GlassFish Server v2 behavior for that application when it is deployed to GlassFish Server 3.0.1.
This change in behavior is also discussed in Chapter 1, GlassFish Server Compatibility Issues, in Oracle GlassFish Server 3.0.1 Upgrade Guide.
In Oracle GlassFish Server 3.0.1, running the deploy --retrieve and get-client-stubs commands no longer downloads just one JAR file to your local directory as in GlassFish Server v2. While localdir/myAppClient.jar is still created in GlassFish Server 3.0.1 and can be used as a target in the appclient command, another directory is also created, localdir/myAppClient, which in turn might contain other files.
If you typically copy the single GlassFish Server v2 downloaded JAR file as a way to move the application client components from one place to another, that will not work in GlassFish Server 3.0.1. The supported method is to use the asadmin get-client-stubs command for that purpose. For more information about the command, see get-client-stubs(1).
If you still choose to copy, however, you must copy not only the localdir/myAppClient.jar file (as in GlassFish Server v2), but also all of the contents of the localdir/myAppClient directory.