22 Deploying Applications

This chapter describes how to deploy JDeveloper applications to the JDeveloper integrated application server, or to a target application server, for example to Oracle WebLogic Server or to a third-party server.

This chapter includes the following sections:

• About Deploying Applications

• Running Java EE Applications in the Integrated Application Server

• Connecting and Deploying Java EE Applications to Application Servers

• Deploying Java Applications

• Deploying Java EE Applications

• Post-Deployment Configuration

• Testing the Application and Verifying Deployment

• Deploying from the Command Line

• Deploying Using Java Web Start

• Deploying Using Weblogic SCA Spring

• Troubleshooting Deployment

22.1 About Deploying Applications

Deployment is the process of packaging application files as an archive file and transferring it to a target application server. You can use JDeveloper to deploy Java or Java EE applications directly to the application server (such as Oracle WebLogic Server or IBM WebSphere), or indirectly to an archive file as the deployment target, and then install this archive file to the target server.

For application development, you can use JDeveloper to run an application in the integrated application server.

If you are using Oracle Fusion Middleware extensions, refer to the appropriate developer's guide for deployment information specific to the product. For example, if you are deploying an ADF Fusion Web application, see the "Deploying Fusion Web Applications" chapter in Developing Fusion Web Applications with Oracle Application Development Framework.

You can deploy applications in the following ways:

• Directly to an application server through an application server connection.

• To an archive file. You can deploy applications indirectly by choosing an archive file as the deployment target. The archive file can subsequently be installed on the target Java EE application server.

• To a test environment using the JDeveloper integrated application server, a Java EE runtime service used for running and testing JDeveloper applications and projects as Java EE applications and modules within a Java EE container.

Note:

Normally, you use JDeveloper to deploy applications for development and testing purposes. If you are deploying applications for production purposes, you can use Enterprise Manager or scripts to deploy to production-level application servers.

For more information about deployment to later-stage testing or production environments, refer to the appropriate developer's guide for deployment information specific to the product.

The figure shows the flow diagram that describes the overall deployment process. Note that preparing the target application server for deployment is outside the scope of this guide; you should refer to the appropriate documentation for a third-party application server.

Figure 22-1 Deployment Overview Flow Diagram

Description of "Figure 22-1 Deployment Overview Flow Diagram"

Java and Java EE applications are based on standardized, modular components and can be deployed to the following application servers:

• Oracle WebLogic Server

  Oracle WebLogic Server provides a complete set of services for those modules and handles many details of application behavior automatically, without requiring programming.

• Oracle Glassfish Server

  You can deploy to Oracle GlassFish Server

• A third-party application server, that is an application server provided by a vendor other than Oracle:

  • Apache Tomcat

  • IBM WebSphere

  • JBoss

  • GlassFish Server Open Source Edition

  For information about which server versions are compatible with JDeveloper, see the JDeveloper Certification Information at http://www.oracle.com/technetwork/developer-tools/jdev/documentation/index.html.

You can also deploy applications to Oracle Java Cloud Service. For more information, see Developing Applications to Deploy to Oracle Java Cloud Service.

You can use JDeveloper to:

• Run applications in the integrated application server

  You can run and debug applications using Integrated WebLogic Server and then deploy to a standalone WebLogic Server or to a third party server.

• Deploy directly to the standalone application server

  You can deploy applications directly to the standalone application server by creating a connection to the server and choosing the name of that server as the deployment target.

• Deploy to an archive file

  You can deploy applications indirectly by choosing an EAR file as the deployment target. The archive file can subsequently be installed on a target application server.

Deployment can be an iterative process where refinements to the application, or corrections to issues in the deployed application, require redeployment to either the test deployment environment, archive file, or application server. The process of deploying an application from JDeveloper can involve a number of processes.

22.1.1 Developing Applications with the Integrated Application Server

JDeveloper is bundled with an integrated application server called Integrated WebLogic Server and a default connection called IntegratedWebLogicServer is defined for it. The integrated application server is a Java EE runtime for services using deployment optimized for the iterative code development cycle. You can use it for running and testing JDeveloper applications and projects as Java EE applications and modules within a Java EE container, as well as for post-run services such as launching a browser or tester. JDeveloper has a default connection to the integrated application server and does not require any deployment profiles or descriptors. In most cases, deploying to the integrated application server is a one-click operation, for example, running a web service by choosing Run from the right-mouse menu of the web service in the Applications window, or running an application by clicking Run on the JDeveloper main menu.

If you want to debug the application use the features described in Running and Debugging Java Projects .

22.1.2 Developing Applications to Deploy to Standalone Application Servers

Typically, for deployment to standalone application servers, you test and develop your application by running it in the integrated application server. You can then test the application further to more closely simulate the production environment by deploying it to standalone Oracle WebLogic Server in development mode or to a third-party application server.

In general, you use JDeveloper to prepare the application or project for deployment by:

• Creating a connection to the target application server. See How to Create a Connection to the Target Application Server.

• Creating deployment profiles (if necessary). See How to Create and Edit Deployment Profiles.

• Creating deployment descriptors (if necessary, and that are specific to the target application server). How to Create and Edit Deployment Dependencies.

• Updating application.xml and web.xml to be compatible with the application server (if required). Viewing or Modifying Deployment Descriptor Properties.

• Migrating application-level security policy data to a domain-level security policy store. See Setting Up JDBC Data Sources on .

You must already have an installed application server. For Oracle WebLogic Server, you can use the Oracle 11g Installer or the Oracle Fusion Middleware 11g Application Developer Installer to install one. For other applications servers, follow the instructions in the applications server documentation to obtain and install the server.

You must prepare the application server by creating a global JDBC data source for applications that require a connection to a data source.

After the application and application server have been prepared, you can:

• Use JDeveloper to:

  • Directly deploy to the application server using the deployment profile and the application server connection.

  • Deploy to an EAR file using the deployment profile.

• Use Enterprise Manager, scripts, or the application server's administration tools to deploy the EAR file created in JDeveloper. See Deploying Oracle ADF Applications.

22.1.3 Developing Applications to Deploy to Oracle Java Cloud Service

Developing an application for deployment to Oracle Java Cloud Service is similar to developing an application for deployment to an application server. See Developing Applications for Oracle Java Cloud Service - SaaS Extension.

You must:

• Ensure that the application is written in code that is valid to run on Oracle Java Cloud Service.

• Create a connection to your Oracle Java Cloud Service instance.

More information about Oracle Cloud services is available at http://docs.oracle.com/cloud/latest/index.html.

22.1.4 Understanding the Archive Formats

A Java EE archive file contains a Java EE module or application. A module consists of one or more JDeveloper projects of a common component type, which have been configured for deployment. An application is comprised of one or more modules. An archive also contains a deployment descriptor, which is an XML file that describes the configuration of the module or application to the server, and is specific to the type of server. A deployment descriptor can be server specific or generic for Java EE servers.

JAR, EJB JAR, and WAR files each contain a module consisting of one or more components. An Enterprise Archive (EAR file) contains an application consisting of one or more modules.

When you create a web (servlet, JSP, JSF, and ADF Faces) or EJB application and deploy it via an application server connection, JDeveloper packages it as a WAR or EJB JAR, which you can optionally wrap in an EAR file. If your application consists of components of differing types, the components will be packaged into multiple modules, which you can deploy independently or assembled as an EAR file.

22.1.5 Understanding Deployment Profiles

Deployment profiles are application or project properties that govern the deployment of a project or application. A deployment profile names the source files, deployment descriptors, and other auxiliary files that will be packaged, the type and name of the archive file to be created, dependency information, platform-specific instructions, and other information.

22.1.6 Understanding Deployment Descriptors

Deployment descriptors define the content and organization of the deployed applications. Deployment descriptor files that are required by an application depend on the technologies the application uses and on its target application server.

22.1.7 Configuring Deployment Using Deployment Plans

You can control how an application is deployed using a deployment plan which allows you to make configuration adjustments in the application deployment descriptors web.xml, weblogic.xml, application.xml, and weblogic-application.xml.

Deployment plans are controlled using a descriptor called plan.xml. Only Weblogic deployment descriptor configuration can be customized using plan.xml. The primary use case for deployment customization is to modify Weblogic specific application configuration for different servers being deployed without requiring modification of the base Weblogic descriptor. See Understanding WebLogic Server Deployment Plans.

22.1.8 Deploying from the Java Edition

If you are using the Java edition of JDeveloper, which contains only the core Java and XML features, the only deployment actions you can perform are:

• Creating a simple JAR archive which you can then manually deploy to a server.

  JDeveloper Java Edition provides the facility to package applications into a JAR file. The deployment dialog in Java Edition allows for only limited configuration of standard JAR options such as specifying JAR name, file groupings, or dependencies on other deployment profiles. Any application that requires more configuration than this must be deployed from the Studio edition of JDeveloper.

• Creating deployment profiles as part of extension development. See Packaging the Extension.

22.2 Running Java EE Applications in the Integrated Application Server

JDeveloper is installed with Integrated WebLogic Server, an integrated application server which you can use to test and develop your application.

For most development purposes, the integrated application server will suffice. When your application is ready to be tested, you can select the run target and then choose the Run command from the main menu.

Note:

The first time you start the integrated application server by running or debugging a project, file, or web service, a dialog is displayed where you enter a password for the administrator ID on the default domain. When you click OK, the default domain is created. You only need to do this once.

When you run the application target, JDeveloper detects the type of Java EE module to deploy based on artifacts in the projects and application. JDeveloper then creates an in-memory deployment profile for deploying the application to the integrated application server. JDeveloper copies project and application files to an "exploded EAR" directory structure. This file structure closely resembles the EAR file structure that you would have if you were to deploy the application to an EAR file. JDeveloper then follows the standard deployment procedures to register and deploy the "exploded EAR" files into the integrated application server. The "exploded EAR" strategy reduces the performance overhead of packaging and unpackaging an actual EAR file.

In summary, when you select the run target and run the application in the integrated application server, JDeveloper:

• Detects the type of Java EE module to deploy based on the artifacts in the project and application

• Creates a default deployment profile (that is, without customizations) in memory

• Copies project and application files into a working directory with a file structure that simulate the "exploded EAR" file of the application.

• Performs the deployment tasks to register and deploy the simulated EAR into the integrated application server

• Automatically migrates identities, credentials, and policies. If you plan to deploy the application to a standalone Oracle WebLogic Server instance, you will need to migrate this security information.

Note:

When you run the application in the integrated application server, JDeveloper ignores the deployment profiles that have been created for the application.

The application will run in the base domain in the integrated application server. The base domain has the same configuration as a base domain in a standalone Oracle WebLogic Server instance. In other words, this base domain is the same as if you had used the Oracle Fusion Middleware Configuration Wizard to create a base domain with the default options in a standalone Oracle WebLogic Server instance.

JDeveloper extends this base domain with the necessary domain extension templates, based on the JDeveloper technology extensions. For example, if you have installed JDeveloper Studio, JDeveloper will automatically configure the integrated application server environment with the ADF runtime template (JRF Fusion Middleware runtime domain extension template).

You can use the Application Server Properties dialog to edit the port you want the application to use. However you cannot specify a port number lower than 1024. This setting can be found on the Configuration page of the Application Server Properties dialog. Open the Application Server Navigator, right-click IntegratedWebLogicServer and choose Properties, then click the Configuration tab and enter the desired port number (1024 or greater) in the Preferred Port field.

You can explicitly create additional default domains for the integrated application server which you can use to run and test your applications in addition to using the default domain. Open the Application Servers window, right-click IntegratedWebLogicServer and choose Create Default Domain.

22.2.1 Understanding the Integrated Application Server Log Window

The output messages generated when running or debugging an application in the integrated application server are displayed in a log window which has a title of either Running: IntegratedWebLogicServer or Debugging: IntegratedWebLogicServer.

The content of the Integrated WebLogic Server Log Window includes:

• Status log messages about the server and the applications running on the server

• Output from the integrated application server instance's console (in color)

• Messages generated from deploying the application to the integrated application server

• Messages that log the Java EE archives (EAR, WAR, and EJB JAR) as they are created. You can click on the links in the log window to browse the generated archives.

The generated log files are located at jdeveloper-user-home/DefaultDomain/server/DefaultServer/logs.

You can configure diagnostic logging parameters in the logging.xml file. Transient loggers can only be added while the server is running in debug mode.

You can control the level of information sent to the log file using the -verbose element in the jsp-descriptor and logging elements of weblogic.xml. See weblogic.xml Deployment Descriptor Elements.

22.2.2 Rules Governing Deployment to the Integrated Application Server

Deployment to the integrated application server uses default deployment profiles which rely on project metadata for the default mappings. Default contributors to the profiles are based on project dependencies, and the rules governing dependencies are:

1. If project A depends on the build output of project B, then the build output of project B is merged into project A. If project A is a web application, this means the build outputs of project A and project B are both copied into WEB-INF/classes of the resulting WAR.

   Merging implies that you can only have one copy of any particular URI, because it can only exist once within WEB-INF/classes.

2. If project A depends on the deployment profile of project B, for example a JAR profile, then the result of that deployment profile is included in the WEB-INF/lib of the resulting WAR.

3. A project containing a WEB-INF/web.xml is recognized as a web project and a default WAR profile is created for it.

4. A project that contains at least one session EJB bean is recognized as an EJB project and  a default EJB JAR profile is created for it.

5. All libraries marked Deploy by Default for a web project are deployed as a web application library (in the WEB-INF/lib of the WAR).

6. All libraries marked Deploy by Default for an EJB project are deployed as an application library (in the lib of the EAR).

7. If an EJB Project A depends on the build output of Project B, the build output (e.g. classes directory) of Project B is merged with the build output of Project A and deployed in the root directory of the EJB JAR.

22.2.3 Working with Integrated Application Servers

The definition of an integrated application server controls the interaction of the instance with JDeveloper and your computer system.

JDeveloper is bundled with an integrated application server called Integrated WebLogic Server, and a default instance called IntegratedWebLogicServer is defined for it. All applications are bound by default to IntegratedWebLogicServer.

You can modify the properties of the integrated application server that an application is bound to.

Note:

WebLogic Server domains used as integrated application servers must be collocated on the same host as the JDeveloper process.

To modify the properties of the integrated application server that an application is bound to:

1. In the Applications window, select a project.
2. Choose Application > Application Properties.
3. Select Run from the left panel.
4. Select an existing integrated application server in Bind Application to Server Instance, or click Application Server Properties to open the Application Server Properties dialog, where you can change some properties for the integrated application server.
5. Define the other options for the integrated application server, including startup and shutdown options. For more information, press F1 or click Help from within the dialog.

You can create a new integrated application server instances.

22.2.3.1 How to Create a New Integrated Application Server Connection

To define an integrated server connection:

1. In the Application Servers window, right-click Application Servers and choose New Application Server. The Create Application Server Connection wizard opens. For more information at any time, press F1 or click Help from within the wizard.
2. On the Usage page, select Integrated Server. If you want to manage the server from within JDeveloper, select Let JDeveloper manage the lifecycle for this Server Instance on the Name and Domain page, and provide the Domain and Server Instance directories.
3. Complete the wizard.

22.2.3.2 How to Run and Debug with an Integrated Application Server

By default, the integrated application server is automatically started when you run or debug an EJB, servlet, HTML, web service, or JSP project. Alternatively, you can start the integrated application server by clicking Start Server Instance or Debug Server Instance from the Run menu.

After it has been started, an integrated application server does not terminate automatically when you terminate a running Java EE application. Therefore, you can select an object, such as a JSP or a servlet in the Applications window, and choose an option from the Run menu.

You can run or debug a working set, which is a group of files created by applying a named filter to a project, by choosing the Use Current Working Set (Java JEE Only) option from the Run menu.

Once this is enabled, when you select Run or Debug from the context menu of the source editor or from a node in the Applications window, it is the current working set that is run or debugged.

Only a single integrated application server can be run at any given time. Thus, if you attempt to start another instance of the server, JDeveloper will shut down the previous instance and restart the instance in order to perform the requested task on the selected icon in the Applications window. After an integrated application server is started, multiple applications can run on it independently of each other. If an application is running, rerunning the application redeploys the up-to-date version of the application.

To run in an integrated application server, an application must be bound to a server instance. JDeveloper is supplied with a WebLogic Server domain, and a default server instance named DefaultServer is defined for it. The unique integrated application server connection defined for this integrated application server is called IntegratedWebLogicServer, and has the Domain Home defined as the system directory $SYSTEM_ROOT/DefaultDomain. All applications are bound by default to IntegratedWebLogicServer.

22.2.3.3 Working with the Default Domain

If you have not explicitly created the integrated application server's default domain, it will automatically be created with default settings when you start the server by running or debugging an application.

Alternatively, you can explicitly create the default domain from the Application Servers window.

If necessary, you can delete the existing default domain so that you can create it again to use new values.

To explicitly create the integrated application server's default domain:

1. If necessary, open the Application Servers window by choosing Window > Application Servers.

2. Right-click the integrated application server connection IntegratedWebLogicServer and choose Create Default Domain. The Configure Default Domain dialog opens, where you can accept the defaults, or explicitly set other values, such as choosing a different listen address. For more information at any time, click Help or press F1 from the Configure Default Domain dialog.

When you install extensions to JDeveloper you may have to update the integrated application server's default domain.

To update the integrated application server's default domain:

1. If necessary, open the Application Servers window by choosing Window > Application Servers.
2. Right-click the integrated application server connection IntegratedWebLogicServer and choose Update Default Domain.

If you have already created the default domain, but you need to use specific settings you can delete the existing default domain and create it again.

To delete the integrated application server's default domain, With JDeveloper closed, locate the system folder in the file system and delete it. When you restart JDeveloper, you can create a new default domain for the integrated application server.

After the server has started, select Processes from the Window menu to display the integrated application server process.

Note:

You can run more than one application simultaneously on a server in run mode, however you can only debug one application at a time in debug mode. To return JDeveloper back into non-debug editing mode, the integrated application server must be shut down.

22.2.3.4 One-Click Running of Applications in the Integrated Application Server

You can test an application by running it in the integrated application server. You can also set breakpoints and then run the application with the integrated application server in debug mode. For more information about running and debugging, see Running and Debugging Java Projects .

To run an application in the integrated application server:

1. In the Applications window, select the run target, for example a project, web service, unbounded task flow, or JSF page.

2. Right-click the run target and choose Run or Debug. Alternatively, choose Run or Debug from the main menu.

   The first time you start the integrated application server by running or debugging an application, a dialog is displayed where you enter a password for the default user weblogic on the default domain. When you click OK, the default domain is created. You only need to do this once.

Application-level and Global Data Sources

If you are deploying to an integrated application server, you can use application level data sources or global data sources.

For both one-click deployment to an integrated application, JDeveloper ensures that your web application web.xml, or EJB application ejb-jar.xml, contains the necessary <resource-ref> entry to identify an application resource name. The name is jdbc/connection-nameDS, where connection-name is the name of the application resources connection.

The application looks up this data source using the application-specific resource JNDI namespace of java:comp/env/jdbc/connection-nameDS, and it finds this resource because web.xml contains the <resource-ref> entry for jdbc/connection-nameDS.

To use application level data sources in one-click deployment to Integrated WebLogic Server, select Auto Generate JDBC Connections When Running Application in JDeveloper on the WebLogic page of the Application Properties dialog (available from the Application menu). This:

• Generates a file called connection-name-jdbc.xml in the /META-INF directory of the application's EAR file

• Creates a corresponding <module> entry in the weblogic-application.xml file in META-INF that references this JDBC module

If the application uses more than one application resources database connection, then a connection-name-jdbc.xml file will be created for each, and there will be a similar number of <module> entries in the weblogic-application.xml file.

To use global data sources in one-click deployment to Integrated WebLogic Server, deselect Auto Generate JDBC Connections When Running Application in JDeveloper on the WebLogic page of the Application Properties dialog (available from the Application menu), and:

1. Connect to the Integrated WebLogic Server Administration Console, described in How to Log In to the Integrated WebLogic Server Administration Console.

2. Create the global data source in a similar manner to creating one on Oracle WebLogic Server, see Setting Up JDBC Data Sources on .

22.2.3.5 How to Start the Integrated Application Server

By default, the integrated application server is automatically started when you run or debug an EJB, servlet, or JSP project. Therefore, you can select an object, such as a JSP or a servlet in the Applications window, and choose an option from the Run menu.

Note:

The first time you start the integrated application server by running or debugging a project, file, or web service, a dialog is displayed where you enter a password for the administrator ID on the default domain. When you click OK, the default domain is created. You only need to do this once.

Only a single integrated application server can be run at any given time. Thus, if you attempt to start another instance of the server, JDeveloper will shut down the previous instance and restart the instance in order to perform the requested task on the selected icon in the Applications window.

After the server has started, open the Processes window to display the integrated application server process. You can open the Processes window by choosing Window > Processes from the main menu.

To start an integrated application server:

1. If necessary, open the Application Servers window by choosing Window > Application Servers.

2. Right-click the Integrated WebLogic Server connection and choose Start Server Instance.

Alternatively, choose Run > Start Server Instance from the main menu.

To start an integrated application server in debug mode:

1. If necessary, open the Application Servers window by choosing Window > Application Servers.
2. Right-click the Integrated WebLogic Server connection and choose Debug Server Instance.

Alternatively, choose Run > Debug Server Instance from the main menu.

22.2.3.6 How to Cancel a Running Deployment

If you are running a large application on the integrated application server, you can cancel it before it has finished deploying.

To cancel a running deployment, In the Log Window, click the Terminate button and choose the profile or application you want to cancel.

22.2.3.7 How to Terminate an Integrated Application Server

After an integrated application server has started, the integrated application server process appears in the Processes window. For more information, see Understanding the Processes Window.

You can open the Processes window by choosing Window > Processes from the main menu.

Note:

Applications deployed on an integrated application server are automatically undeployed whenever the integrated application server is terminated.

The default behavior is to undeploy all the applications, but you can change the behavior.

To shutdown the running integrated application server, do one of the following:

• Choose Run > Terminate > IntegratedWebLogicServer (or the integrated application server connection name) from the main menu.

• Select the integrated application server name from the Terminate dropdown list in the toolbar.

• Choose Window > Processes from the main menu. Right-click the integrated application server name and choose Terminate.

• Choose File > Exit to exit JDeveloper. Click Yes when prompted to terminate the instance's process.

• In the Application Servers window, right click on the integrated application server connection and select Terminate Server Instance.

To force shutdown of Integrated WebLogic Server:

• If you need to force shutdown of Integrated WebLogic Server, press the Terminate button twice.

22.2.3.8 How to Configure Startup and Shutdown Behavior for Integrated Application Servers

You can configure startup and shutdown behavior for integrated application server connections.

To configure the startup and shutdown behavior for an integrated application server:

1. If necessary, open the Application Servers window by choosing Window > Application Servers.
2. Right-click the integrated application server connection and choose Properties to open the Application Server Properties dialog. For more information at any time, press F1 or click Help from within the dialog.

   If you are viewing the properties of the default integrated application server, you can only change settings on the Configuration, Shutdown and Launch Settings tabs in the dialog. Otherwise, you can edit everything except the connection name.

22.2.3.9 How to Log In to the Integrated WebLogic Server Administration Console

The integrated application server is an implementation of Oracle WebLogic Server and as such you can connect to the server's Administration Console.

Note:

To log in to the Administration Console, you must have the integrated application server running from JDeveloper, for example:

• By starting Integrated WebLogic Server from the Application Servers window.

• By running an application.

To launch and log in to the integrated application server Administration Console:

1. If necessary, open the Application Servers window by choosing Window > Application Servers.
2. Right-click IntegratedWebLogicServer and select Launch Administrative Console. A browser instance opens at the login page, which is http://host:port/console.

   For example, if the default configuration is used, the browser uses http://localhost:7001/console.

3. Log in using the username for the default domain and password you used when the integrated application server was launched for the first time.

The integrated application server is an implementation of Oracle WebLogic Server, so for more information about the integrated application server Administration Console refer to the Administration Console Online Help, which is available from the WebLogic Server online documentation in your JDeveloper installation, or from the Administration Console.

22.3 Connecting and Deploying Java EE Applications to Application Servers

Learn how to create connections to application servers, deployment profiles, and deployment descriptors.

Before you deploy an application to a standalone application server, you must perform prerequisite tasks within JDeveloper to prepare the application for deployment.

The figure shows the process flow to prepare the application for deployment. After the application has been prepared and the application server has been prepared, you can proceed to deploy the application.

Figure 22-2 Preparing the Application for Deployment Flow Diagram

Description of "Figure 22-2 Preparing the Application for Deployment Flow Diagram"

22.3.1 How to Create a Connection to the Target Application Server

You can deploy applications to the application server via JDeveloper application server connections.

This section describes how to generically create a connection to an application server. For information about connecting to a specific type of application server, see Connecting to Specific Application Server Types.

Before you begin:

• Ensure that the application server is installed and started.

• If you are working behind a proxy server you may want to be check the proxy settings that JDeveloper is using.

  1. Choose Tools > Preferences to open the Preferences dialog and navigate to the Web Browser and Proxy page. For more information at any time, press F1 or click Help in the Web Browser and Proxy page of the Preferences dialog.

  2. On the Proxy Settings tab you can see the proxy settings that JDeveloper is using, and if necessary change them. By default, JDeveloper uses the system default proxy settings. You can override these by choosing No Proxy, Use Automatic Configuration Script, or Manual Proxy Settings and entering your settings as appropriate. See Configuring Proxy Settings.

To create a connection to an application server:

1. Launch the Application Server Connection wizard in one of the following ways:

   • In the Application Servers window, right-click Application Servers and choose New Application Server.

   • In the New Gallery, expand General, select Connections and then Application Server Connection, and click OK.

   • In the Resources window, choose New > New Connection > Application Server.

2. If the Usage page of the wizard is displayed, ensure that Standalone Server is selected and click Next.

3. In the Name and Type page, enter a name for your new connection.

4. In the Connection Type dropdown list, choose the type of application server you want to create a connection to. The options are:

   • WebLogic 10.3 or WebLogic 12.x to create a connection to Oracle WebLogic Server

   • GlassFish 3.1 to create a connection to Oracle GlassFish Server or GlassFish Open Source Edition

   • JBoss 5.x to create a connection to JBoss

   • Tomcat 7.x to create a connection to Tomcat

   • WebSphere Server 8.x to create a connection to IBM WebSphere Server

   • Oracle Cloud to create a connection to Oracle Java Cloud Service

5. Click Next.

6. On the Authentication page, enter a user name and password for the administrative user authoriweblogic1zed to access the application server.

7. Click Next.

8. On the Configuration page, enter the parameters to create a connection to the application server:

9. Click Next.

10. If you have chosen WebSphere, the JMX page appears where you enter JMX configuration values needed for deploying SOA applications.

11. Click Next.

12. On the Test page, click Test Connection to test the connection.

    JDeveloper performs several types of connections tests. The JSR-88 test must pass for the application to be deployable. If the test fails, return to the previous pages of the wizard to fix the configuration.

13. Click Finish.

How to Launch Oracle WebLogic Server Administration Console

You can launch and connect to the Oracle WebLogic Server Administration Console from the Application Servers window.

Note:

To log in to the console, the server must be started.

1. In the Application Servers window, right-click the name of the connection to the Oracle WebLogic Server instance, and choose Launch Admin Console. A browser instance opens at the login page, which is http://host:port/console.

   For example, if the default configuration is used, the browser uses http://localhost:7001/console.

2. Log in using the username and password you used when creating the connection to the Oracle WebLogic Server instance. If you are launching the Administration Console for Integrated WebLogic Server, the default user is weblogic and the password you entered when the default domain was created.

For more information about the WebLogic Server Administration Console, refer to the Administration Console Online Help, which is available from the WebLogic Server online documentation in your JDeveloper installation, or from the Administration Console.

22.3.2 Connecting to Specific Application Server Types

This section contains the specific information for accounting to different types of application server.

JDeveloper supports deploying to server clusters, but you cannot use JDeveloper to deploy to individual managed servers that are members of a cluster.

22.3.2.1 Connecting to Oracle WebLogic Server

To connect to Oracle WebLogic Server:

• The Oracle WebLogic host name is the name of the WebLogic Server instance containing the TCP/IP DNS where your application (.jar,.war,.ear,.gar) will be deployed.

• In the Port field, enter a port number for the Oracle WebLogic Server instance on which your application (.jar,.war,.ear,.gar) will be deployed.

  If you do not specify a port, the port number defaults to 7001.

• In the SSL Port field, enter an SSL port number for the Oracle WebLogic Server instance on which your application (.jar,.war,.ear,.gar) will be deployed.

  Specifying an SSL port is optional. It is required only if you want to ensure a secure connection for deployment.

  If you do not specify an SSL port, the port number defaults to 7002.

• Select Always Use SSL to connect to the Oracle WebLogic Server instance using the SSL port.

• Optionally enter a WebLogic Domain only if Oracle WebLogic Server is configured to distinguish non administrative server nodes by name.

22.3.2.2 Connecting to GlassFish

If you are creating a secure connection to a GlassFish server, you must use the host name, for example localhost, instead of an IP address in Host name on the Configuration page, otherwise, the connection will fail. This is because the host name in the URL used to create the connection the server must match the host name in the certificate.

22.3.2.3 Connecting to JBoss

For JBoss:

• Enter or browse to the location of the JBoss deploy directory, where your application files (.jar,.war,.ear,.gar) are.

• If you are using JMX, Select Enable JMX for this connection. (optional).

  Note:

  JMX configuration is optional and is not required for connecting to the JBoss Application Server. JMX is only needed for deploying SOA applications.

  You must use the Oracle JMX RMI connector (oracle-jboss-remoting.sar) on the JBoss server; the standard JBOSS JMX connector (jmx-remoting.sar) does not work with JDeveloper.

• In the Host Name field, enter host name of the target server. The default is the machine name.

• In the RMI Port field, enter the port number of JBoss's RMI connector port. The default is 19000.

22.3.2.4 Connecting to Tomcat

For Tomcat:

• In the Webapps Directory field enter or browse to the location of the webapps directory where you place the application .war files.

22.3.2.5 Connecting to WebSphere Server

For WebSphere:

• In the Host Name field, enter the name of the WebSphere server containing the TCP/IP DNS where your Java EE applications (.jar, .war, .ear, [.gar]) are deployed. If no name is entered, the name defaults to localhost

• In the SOAP Connector Port field, enter the port number. The host name and port are used to connect to the server for deployment. The default SOAP connector port is 8879

• In the Server Name field, enter the name assigned to the target application server for this connection.

• In the Target Node field, enter the name of the target node for this connection. A node is a grouping of Managed Servers. The default is machineNode01, where machine is the name of the machine the node resides on

• In the Target Cell field, enter the name of the target cell for this connection. A cell is a group of processes that host runtime components. The default is machineNode01Cell, where machine is the name of the machine the node resides on.

• In the Wsadmin script location field, enter, or browse to, the location of the wsadmin script file to be used to define the system login configuration for your IBM WebSphere application server connection. Note that you should not use the wsadmin files from the ORACLE_HOME/oracle_common/common/bin directory, which are not the correct version. The default location is websphere-home/bin/wsadmin.sh for Unix/Linux and websphere-home/bin/wsadmin.bat for Windows.

  Note:

  When the script file is specified you can encounter problems if the path contains a space. For example, C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\AppSrv01\bin\wsadmin.bat To work around this problem, use an OS short name for the directory with a space in the name (for example, Progra~1), or create a WebSphere application server instance in a path that does not have spaces and refer to the batch file there.

• If you have chosen WebSphere, the JMX page appears. On the JMX page, enter the JMX information (optional):

  Note:

  JMX configuration is optional and is not required for connecting to the WebSphere Application Server. JMX is only needed for deploying SOA applications.

  • Select Enable JMX for this connection to enable JMX.

  • In the RMI Port field, enter the port number of WebSphere's RMI connector port. The default is 2809.

  • In the WebSphere Runtime Jars Location field, enter or browse to the location of the WebSphere runtime JARs.

  • In the WebSphere Properties Location (for secure MBEAN access) field, enter or browse to the location of the file that contains the properties for the security configuration and the mbeans that are enabled. This field is optional.

22.3.2.6 Connecting to Oracle Java Cloud Service

After you sign up for Oracle Java Cloud Service, you will receive information about the data center, the identity domain, and the service name which you use to establish a connection to your Oracle Java Cloud Service instance:

To connect to the Oracle Java Cloud Service, you need to enter the following information:

• On the Authentication page, enter the administration username and password.

• On the Configuration page, choose the data center and enter the identity domain and service name for your Oracle Java Cloud Service instance.

22.3.3 How to Create and Edit Deployment Profiles

A deployment profile defines the way the application is packaged into the archive that will be deployed to the target environment. The deployment profile:

• Specifies the format and contents of the archive file that will be created

• Lists the source files, deployment descriptors, and other auxiliary files that will be packaged

• Describes the type and name of the archive file to be created

• Highlights dependency information, platform-specific instructions, and other information

22.3.3.1 About Deployment Profiles

Deployment to application servers uses deployment profiles which rely on project metadata for the default mappings. Default contributors to the profiles are based on project dependencies, although you can customize the deployment profiles to change them.

The rules governing dependencies are:

1. If project A depends on the build output of project B, then the build output of project B is merged into project A. If project A is a web application, this means the build outputs of project A and project B are both copied into the WEB-INF/classes of the resulting WAR.

   Merging implies that you can only have one copy of any particular URI, because it can only exist once within WEB-INF/classes.

2. If project A depends on the deployment profile of project B, for example a JAR profile, then the result of that deployment profile is included in the WEB-INF/lib of the resulting WAR.

3. All libraries marked Deploy by Default for a web project are deployed as a web application library (in the WEB-INF/lib of the WAR).

4. All libraries marked Deploy by Default for an EJB project are deployed as an application library (in the lib of the EAR).

5. All libraries marked Deploy by Default at the application level are deployed as an application library (in the lib of the EAR).

6. If an EJB Project A depends on the build output of Project B, the build output (for example, classes directory) of Project B is merged with the build output of Project A and deployed in the root directory of the EJB JAR.

Application level deployment profiles are:

• EAR files: Used to deploy the Java EE enterprise archive (EAR) file. The EAR file consists of the application's assembled WAR, EJB JAR, and client JAR files.

• MAR files: Used for deploying metadata archive files for seeded customizations or base metadata in an MDS repository in the application server. For more information about MAR files, refer to the appropriate developer's guide for the Oracle Fusion Middleware product you are using.

Project level Java EE deployment profiles are:

• Business Components Archive: Creates a simple archive file for deploying ADF Business Components.

• Business Components Service Interface: Creates a profile for deploying ADF Business Components as a service interface.

• Client JAR File: Used for deploying the standard Java EE client JAR file.

• EJB JAR File: Used to deploy the Java EE EJB module (EJB JAR). The EJB JAR contains the EJB components and the corresponding deployment descriptors.

• Extension JAR: Creates a profile for deploying an extension as a JAR file.

• JAR file: Creates a simple JAR archive from a project.

• GAR file: Creates an Oracle Coherence grid archive file. The GAR contains the artifacts of a Coherence application and includes a deployment descriptor.

• MOF Model Library: Creates MOF (Meta-Object Facility) Model Library JAR files which enable UML objects from one project to be reused by another.

• OSGi Bundle: Creates an OSGi bundle that can be deployed to an OSGi container. You use this when you create extensions to JDeveloper.

• RAR file: Creates a profile for deploying a Java EE connector RAR file.

• Shared Library JAR file: Creates a profile for deploying a simple archive, which can be a JAR of ZIP file, to the file system or as a shared library to a remote server.

• Taglib JAR file: Creates a profile for deploying custom tag libraries to a JAR file.

• WAR files: Used to deploy the JAVA EE web module (WAR). The WAR consists of the web components (JSPs and servlets) and the corresponding deployment descriptors.

22.3.3.2 Creating Deployment Profiles

To create a deployment profile, select an application or a project then choose File > New > From Gallery, and from the General category, choose Deployment Profile. To create application level profiles, invoke the New Gallery at application level.

Other methods can be used to create a deployment profile:

• Use the Application Properties Deployment dialog:

  • From the JDeveloper toolbar, select Application > Deploy > New Deployment Profile...

  • Right-click on an application and select Deploy > New Deployment Profile... from the context menu.

  • In the Applications window, open the dropdown list on the Applications window toolbar. and choose Deploy.

• Use the Project Properties Deployment dialog:

  • Select the project in the Applications window, then from the menu, choose Application > Project Properties. Choose Deployment, and in the Deployment panel on the right, click the New Profile icon on the menu bar.

  • The context menu of a project in the Applications window.

To modify an existing deployment profile:

• Right-click the project in the Applications window and choose Project Properties then choose Deployment in the tree structure in the wizard, then select the deployment profile and choose Edit.

• Right-click the application in the Applications window and choose Application Properties then choose Deployment in the tree structure in the wizard, then select the deployment profile and choose Edit.

To activate profile deployment:

• For a project level deployment profile, right-click the project in the Applications window then choose Deploy > deployment profile.

• For an application deployment profile, right-click the application in the Applications window then choose Deploy > deployment profile. Alternatively,

  • Right-click the application in the Applications window then choose Deploy > deployment profile.

  • Choose Deploy > deployment profile from the context menu of an application.

  • Choose Deploy > deployment profile from the dropdown list on the Applications window toolbar.

The project and any projects on which it depends will be compiled and packaged.

You may find that the application you created already contains the deployment profile you need, for example if you create a web-based project you should already have a default WAR deployment profile which includes the dependent model projects it requires.

To create a deployment profile:

1. For an application level deployment profile, in the Applications window, right-click the application and choose New.

   For a project level deployment profile, in the Applications window, right-click the project that you want to deploy and choose New.

2. In the New Gallery, expand General, select Deployment Profiles and then choose the deployment profile type you want, and click OK.

   If you don't see Deployment Profiles in the Categories tree, click the All Features tab.

3. Choose the deployment profile type you want to create, and click OK. For example, for an EAR deployment profile:

   • Select Application Assembly and then in the Java EE Modules list, select all the project profiles that you want to include in the deployment, including any WAR profiles.

   • (Optional) Select Platform, select the application server you are deploying to, and then select the target application connection from the Target Connection dropdown list.

     By default, deployment will set this platform at deployment time to match the server you are deploying to. When you are deploying to a file, the default will be the "default platform" which is the latest Oracle Weblogic server release, in this case, Oracle WebLogic Server 12.x.

4. In the Edit Deployment Profile Properties dialog, configure the profile by setting property values. For example, you may want to change the file groups that are included in the profile. When you have finished, click OK.

Deployment profiles are available from the Application Properties dialog, for application level deployment profiles, or from the Project Properties dialog, for project level deployment profiles, and you can edit them or delete them.

22.3.3.3 Viewing and Changing Deployment Profile Properties

After you have created a deployment profile, you can view and change its properties.

To edit or delete a deployment profile:

1. For an application level deployment profile, choose Application > Application Properties to open the Application Properties dialog.

   For a project level deployment profile, choose Application > Project Properties to open the Project Properties dialog.

2. Click Deployment in the left panel to open the Deployment page.
3. Choose the deployment profile you want to edit or delete, and click:

   • Edit to open the Edit Deployment Profile Properties dialog.

   • Delete to delete the deployment profile.

22.3.3.4 Configuring Deployment Profiles

Configuring is the process of assembling an archive file from its component files. Configuring is specified in the File Groups branch of deployment profile properties dialogs.

The File Groups branch consists of a list of file groups, each specifying some components. The packaged archive will be the union of all the file groups. The order of the file groups resolves name collisions: if two files have the same name, the one from the file group higher in the list is included, and the one from the lower file group is omitted.

A newly created deployment profile will include one or more predefined file groups. You can add, delete, and edit file groups.

File groups are defined by a set of contributors pruned by a set of filters. Contributors are source files, JAR files, and directories that are selected for inclusion. Filters are rules that are applied to the contributors or contributor's component subdirectories and files to identify the set and files that will be packaged. There are three kinds of file groups:

• The Packaging file group type allows you to select contributors, project directories and other directories and JAR files, and filters. The file group mechanism is flexible and transparent, and is appropriate for most projects.

• The Libraries file group type allows you to select contributors that are project libraries. A libraries file group is created for WAR deployment profiles. Libraries files groups are useful in other projects that need to repackage existing JAR files.

22.3.4 How to Create and Edit Deployment Dependencies

Deployment dependencies between the components of an application are stated in their project's deployment profiles. In a project's deployment profile, name the profiles for the projects that are immediately upstream. When a deployment profile is activated for deployment, its dependencies will first be deployed.

Set deployment profile dependencies on the deployment profile's Profile Dependencies page. Only deployment profiles in the current application are listed and available for selection. Click the Help button for more information. The various profile dependencies you can select include:

• Profile-to-profile dependency

• Profile-to-JAR dependency

• Profile-to-WAR dependency

• Profile-to-RAR (Resource Archive) dependency

When deploying a profile contained in a project that has project-to-profile dependencies on other profiles, at deploy-time the profile incorporates the dependencies specified in the project. For example, if Project1.jpr contains Servlet1.java and depends on ejb1.jar, and project2.jpr contains MySessionEJB and ejb1.jar, then deploying the first project will result in an EAR file containing both webapp1.war and ejb1.jar.

When creating profile dependencies between JAR, WAR, and EJB JAR modules that share common JAR files, you can use the META-INF/MANIFEST.MF Class-Path attribute to link JAR files together at deploy-time. From the deployment profile properties JAR options page, select Include Manifest File (META-INF/MANIFEST.MF). Doing so causes a single shared copy of any common JARs to be included in the EAR file.

Dependency projects can have dependencies of their own, but cyclical dependencies should be avoided. When JDeveloper encounters a circular dependency it will attempt to deploy anyway, but a warning will be displayed in the log window.

22.3.4.1 About Library Dependencies

Dependent libraries are any library needed for a module to compile and run. In the Libraries and Classpath page of the Project Properties dialog for the project containing the library, dependent libraries are shown as available for export.

In an application, dependent libraries can be in the following projects:

• Projects of the current module's profile, that is the profile container.

• Projects that the profile container depends on.

• Projects associated with any profile dependency for this module's profile (recursively to its profile and project dependencies).

The example below illustrates project dependencies (arrows on the left) and profile dependencies (arrows on the right).

Figure 22-3 Dependencies Between Projects and Deployment Profiles

Description of "Figure 22-3 Dependencies Between Projects and Deployment Profiles "

Project dependencies are recursive at deployment time, even though they are not at compile time, which is why the libraries from JavaProject are considered dependent libraries. WebProfile, which represents a web module, has the following dependent libraries:

• EjbDepLib (a library from a project dependency to WebProject)

• EjbDep.jar (a library jar from a project dependency to WebProject)

• JavaDepLib (a library from a recursive project dependency to JavaProject)

• JavaDep.jar (a library jar from a recursive project dependency to JavaProject)

• SampleLib (a library from a profile dependency)

• Sample.jar (a library jar from a profile dependency)

• OtherLib (a library from a recursive profile dependency)

• Other.jar (a library jar from a recursive profile dependency)

22.3.4.1.1 Resolved and Unresolved Libraries

Dependent Libraries can either be resolved or unresolved. Dependent libraries are considered unresolved until they are included in an archive and placed on the classpath, thereby making the library content available to classes that need to reference it.

For example, a WAR profile resolves libraries by selecting those libraries in a library file group contributor where the target output directory is WEB-INF\lib. This ensures that the WAR archive created will include those libraries in the archive's WEB-INF\lib directory and thereby including the library content on the WAR archive's classpath.

When a library is not resolved by a deployment profile, this profile will expose the unresolved library in the application hierarchy so that it can be resolved at a higher level. Consider the situation where libraries contained in an EJB project remain unresolved from the EJB profile's perspective. This information will be exposed so that an EAR profile can ensure that those libraries are resolved at the EAR level (in the EAR profile's library file group).

In the illustration above, WebProject has a project dependency to JavaProject, and JavaProject includes a library called JavaDepLib. You can define a web application which creates a WAR deployment profile on WebProject. You can then resolve JavaDepLib in the web module by ensuring that this library is selected in the WEB-INF\lib library file group of the WAR deployment profile.

22.3.4.1.2 Manifest Entries for Libraries

When libraries are included in an EAR archive in a directory other than the standard \lib or APP-INF\lib, JDeveloper automatically inserts the required manifest entries into the modules that refer to those libraries.

22.3.5 How to Create and Edit Deployment Descriptors

Deployment descriptors are server configuration files that define the configuration of an application for deployment and that are deployed with the Java EE application as needed. The deployment descriptors that a project requires depend on the technologies the project uses and on the type of the target application server. Deployment descriptors are XML files that can be created and edited as source files, but for most descriptor types, JDeveloper provides dialogs or an overview editor that you can use to view and set properties. If you cannot edit these files declaratively, JDeveloper opens the XML file in the source editor for you to edit its contents.

In addition to the standard Java EE deployment descriptors (for example, application.xml and web.xml), you can also have deployment descriptors that are specific to your target application server. For example, if you are deploying to Oracle WebLogic Server, you can also have weblogic.xml, weblogic-application.xml, and weblogic-ejb-jar.xml.

The essential descriptors are created by the wizards that create deployment profiles. Add other descriptors only if you wish to override default behavior. In some cases descriptors will be created and included in archive files as they are deployed.

Deployment descriptors can also be created from the New Gallery. Deployment descriptors are placed in a META-INF subfolder of a project's Application Sources or WEB-INF subfolder of a project's Web Contents folders.

Each Java EE standard deployment descriptor is extended by a corresponding Oracle WebLogic Server-specific descriptor. Table 22-1 provides a description of these files and illustrates how they relate to one another.

Table 22-1 Deployment Descriptors

Java EE Standard Descriptors	Oracle WebLogic Server Proprietary Descriptors
application-client.xml Describes the EJB modules and other resources used by a Java EE application client deployed as an archive.	weblogic-appclient.xml The file format is defined in weblogic-appclient.xsd. See Client Application Deployment Descriptor Elements.
application.xml Specifies the components of a Java EE application, such as EJB and web modules, and can specify additional configuration for the application as well. This descriptor must be included in the /META-INF directory of the application's EAR file.	weblogic-application.xml The file format is defined in weblogic-application.xsd. See The weblogic-application.xml File.
ejb-jar.xml Defines the specific structural characteristics and dependencies of the Enterprise JavaBeans within a JAR, and provides instructions for the EJB container about how the beans expect to interact with the container.	weblogic-ejb-jar.xml The format of this file is defined in weblogic-ejb-jar.xsd. persistence-configuration.xml For EJB 3.x modules. The format of this file is defined in persistence-configuration.xsd. For more information, see EJB Deployment Descriptors. weblogic-cmp-rdbms-jar.xml
ra.xml Contains information on implementation code, configuration properties and security settings for a resource adapter packaged within a RAR file.	weblogic-ra.xml The format of this file is defined in weblogic-ra.xsd. See weblogic-ra.xml Schema.
web.xml Specifies and configures a set of Java EE web components, including static pages, servlets, and JSP pages. It also specifies and configures other components, such as EJBs, that the web components might call. The web components might together form an independent web application and be deployed in a standalone WAR file.	weblogic.xml The format of this file is defined by weblogic-web-app.xsd. See weblogic.xml Deployment Descriptor Elements.
None.	module-name-jdbc.xml Defines data sources to be used in the deployed application. The format of this file is defined by weblogic-jdbc.xsd. See Data Source Configuration Files. plan.xml The format of this file is defined by deployment-plan.xsd. Contains a list of name/value pairs, and a description of the various deployment descriptors in an application. It allows administrators to override values in deployment descriptors. See Understanding WebLogic Server Deployment Plans. weblogic-diagnostics.xml The format of this file is defined by weblogic-diagnostics.xsd. Used in the WebLogic Server Administration Console to create or modify diagnostic monitors in the diagnostic application module. See Configuring Instrumentation. weblogic-jms.xml The format of this file is defined by weblogic-jms.xsd. Used to configure JMS drivers in the Oracle WebLogic Server. See Understanding WebLogic JMS. weblogic-webservices.xml The format of this file is defined by weblogic-webservices.xsd. See WebLogic Web Service Deployment Descriptor Schema Reference.

22.3.5.1 Creating Deployment Descriptors

JDeveloper automatically creates many of the required deployment descriptors for you. If they are not present, or if you need to create additional descriptors, you can explicitly create them.

Before you begin:

Check to see whether JDeveloper has already generated deployment descriptors.

To create a deployment descriptor:

1. In the Applications window, right-click the project for which you want to create a descriptor and choose New.

2. In the New Gallery, expand General, select Deployment Descriptors and then a descriptor type, and click OK.

   If you cannot find the item you want, make sure that you chose the correct project, and then choose the All Features tab or use the Search field to find the descriptor. If the item is not enabled, check to make sure that the project does not already have a descriptor of that type. A project is allowed only one instance of a descriptor.

   JDeveloper starts the Create Deployment Descriptor wizard and then opens the file in the overview or source editor, depending on the type of deployment descriptor you choose.

   Note:

   For EAR files, do not create more than one of any type of deployment descriptor per application. Only the application resources descriptors or descriptors generated at the EAR level will be used by the runtime. If multiple projects in an application have the same deployment descriptor, the one belonging to the launched project will supersede the others. This restriction applies to application.xml, weblogic-jdbc.xml, jazn-data.xml, and weblogic.xml.

   The best place to create an application-level descriptor is in the Descriptors node of the Application Resources panel in the Applications window. This ensures that the application is created with the correct descriptors.

To inspect or change deployment descriptor properties:

1. In the Applications window, select the deployment descriptor.
2. Right-click and choose Open.

   The file will open in an overview editor specific to that descriptor type, or in an XML editor window.

22.3.5.2 How to Create a Web Service Policy Reference

Follow these steps to create a web service policy reference:

1. Select File > New > WebLogic Deployment Descriptor. From the General category, select Deployment Descriptors; choose the Weblogic item in the right‐hand pane and click OK. The wizard opens.
2. On the Select Descriptor page, scroll down to select webservice-policy-ref.xml.
3. On the Select Version page, select the Deployment Descriptor version and click Next.
4. On the Summary page, click Finish.
5. The new configuration file opens in the editor.

The tabs on the left allow you to edit the Policy Reference Name, the Port Policy, and the Operation Policy separately. The wizard provides Overview, Source, and History views for each setting. See the online help.

22.3.5.3 Viewing or Modifying Deployment Descriptor Properties

After you have created a deployment descriptor, you can change its properties by using JDeveloper dialogs or by editing the file in the source editor. The deployment descriptor is an XML file (for example, application.xml) typically located under the Application Sources node.

To view or change deployment descriptor properties:

1. In the Applications window or in the Application Resources panel, double-click the deployment descriptor.
2. In the overview editor, select either the Overview tab or the Source tab, and configure the descriptor by setting property values.

   If the overview editor is not available, JDeveloper opens the file in the source editor.

22.3.6 How to Configure Global Deployment Preferences

You can set global deployment options in the Deployment page of the Preferences dialog.

To configure the deployment preferences:

1. Choose Tools > Preferences from the main menu.
2. Select the Deployment node. Configure the deployment options as required. For more information, click Help.
3. Click OK.

Note:

Set application-specific and project-specific deployment profile options via the application properties or project properties. The Application Properties and Project Properties dialogs are available from the Application menu

22.3.7 How to Configure Applications for Deployment

This section describes the tasks you may have to perform for the application to deploy successfully to an application server.

22.3.7.1 How to Configure an Application for Deployment to Oracle WebLogic Server

When you create applications in JDeveloper You can deploy the packaged application to Oracle WebLogic Server through an application server connection. A packaged application will contain a deployment profile that names the files to be deployed, describes their organization, and specifies the target server. The target Oracle WebLogic Server instance must be installed locally or mapped to a network drive.

To configure an application for deployment to Oracle WebLogic Server:

1. Set up any JDBC data sources you need on the server. See Setting Up JDBC Data Sources on Oracle WebLogic Server.
2. For clients that access EJBs on Oracle WebLogic Server, the following code is required in the client.

   env.put(Context.INITIAL_CONTEXT_FACTORY, 
     "weblogic.jndi.WLInitialContextFactory"); 
   env.put(Context.SECURITY_PRINCIPAL, "system"); 
   env.put(Context.SECURITY_CREDENTIALS, "welcome1"); 
   env.put(Context.PROVIDER_URL, "t3://localhost:7001"); 
   

3. When deploying to Oracle WebLogic Server, if you use the same EJB in two or more different applications, the second deployment will usually cause a JNDI name collision. Therefore, you must rename the JNDI name of the EJB for the second and any subsequent deployments:

   • Right-click weblogic-ejb-jar.xml, and choose Open.

   • Under Enterprise Java Beans, select the relevant ModuleBM bean. The EJB tab is displayed on the right.

   • In the EJB tab, change the JNDI Name so that it is different from any other JNDI Name in weblogic-ejb-jar.xml and any other EJBs that are already deployed to Oracle WebLogic Server.

   • Deploy the application accessing the EJB to Oracle WebLogic Server. During deployment, the IDE automatically fills in weblogic.xml with appropriate EJB references.

22.3.7.2 How to Configure a Client Application for Deployment

A Java EE Client module is packaged as a client JAR file which contains one or more Java application components and a client deployment descriptor file named application-client.xml. After you have created the deployment profile and the deployment descriptor file, you can deploy the client JAR to the application server.

To package a client application for deployment:

1. Create a Client JAR File deployment profile for your project.

   A profile may have already been created for your project. If you wish to deploy to multiple targets, create a separate profile for each.

2. Create the application-client.xml deployment descriptor file, if not already present in your project.

   Normally, this file is created with the application client.

22.3.7.3 How to Configure an Applet for Deployment

A standalone applet is packaged as a web archive (WAR) file which contains the applet, the Applet HTML file, as well as the standard Java EE web deployment descriptor, web.xml and possibly target-specific deployment descriptors, as well. After you have created the deployment profile and the appropriate deployment descriptor files, you can deploy the application to an application server, or as an archive file.

To configure a web application for deployment:

1. Create a WAR file deployment profile for your project.

   A profile may have already been created for your project. If you wish to deploy to multiple targets, create a separate profile for each.

2. Add a web.xml deployment descriptor to your project, if it is not already present.

   Normally, this file is created with the WAR file deployment profile.

Note:

If you encounter problems when deploying a Swing applet (JApplet), for example, the error Class not found is displayed, this may indicate that JDeveloper cannot locate the Swing libraries. Your clients may need to use Java SE browser plugin or bundle the Swing libraries for JVMs version 1.1 with your applet. Deployed applet files must reside in a separate location from any other web application files you have deployed.

22.3.7.4 Setting Up JDBC Data Sources on Oracle WebLogic Server

To avoid passwords being present in plain text in deployed files, JDeveloper uses password indirection, which means that passwords for the data sources must be set on the server before the application will run correctly.

You do this using global data sources, which are set up in the Oracle WebLogic Server Administration Console using the Data Sources link under JDBC.

JDeveloper ensures that your web application web.xml, or EJB application ejb-jar.xml, contains the necessary <resource-ref> entry to identify an application resource name. The name is jdbc/connection-nameDS, where connection-name is the name of the application resources connection.

The application looks up this data source using the application-specific resource JNDI namespace of java:comp/env/jdbc/connection-nameDS, and it finds this resource because web.xml contains the <resource-ref> entry for jdbc/connection-nameDS.

An important control for the files that are generated is the Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment field on the WebLogic page of the Application Properties dialog.

When the Auto Generate field is selected, JDeveloper does the following:

• Generates an application-name-jdbc.xml file for each connection in the application resources, and sets the indirect password attribute

  <jdbc-driver-params>
  <use-password-indirection>true</use-password-indirection>
  </jdbc-driver-params>
  

  Upon deployment, JDeveloper determines the JDBC connection password from the username in application-name-jdbc.xml, and populates the JDBC connection password using an Mbean.

• weblogic-application.xml is updated to add each application-name-jdbc.xml as a module.

• web.xml (if it exists) has a resource reference to each JDBC JNDI name.

How to Create a Global Data Source on Oracle WebLogic Server

You create a global data source on Oracle WebLogic Server Administration Console.

To set up a global data source:

1. Login to the Oracle WebLogic Server Administration Console. For more information, see How to Create a Connection to the Target Application Server.
2. Click on the Data Sources link under JDBC.
3. On the Summary of JDBC Data Sources page, click New.
4. In the Create a New JDBC Data Source page, enter details of the data source.

   The name can be anything.

   The JNDI name must be of the form jdbc/connection-nameDS. For example, if the application has a connection name connection1, the JNDI name is jdbc/connection1DS.

5. Ensure that the database type is Oracle and that the driver is Oracle's Driver (Thin) for Service Connections;Version 9.0.1,9.2.0,10,11.
6. Click Next twice to navigate to the Create a New JDBC Data Source page, where you enter the connection details.

   The database name is the Oracle SID.

   The host name is the name of the machine the database is on.

   The default port is 1521.

7. Enter the user name and password, for example hr/hr.
8. Click Next and click Test Configuration.
9. Click Next to navigate to the Select Targets page, where you select a target for this data source. If you fail to select a target, the data source is created but not deployed.
10. Click Finish.

Example 22-1 Deploying to an EAR File to Run on Oracle WebLogic Server

To deploy an application to an EAR file to run on Oracle WebLogic Server, you can:

• Select the Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment field, and set up passwords using application level credential mapping.

• Alternatively, you can deselect the Auto Generate and Synchronize weblogic-jdbc.xml Descriptors During Deployment field and set up passwords by creating a global data source on Oracle WebLogic Server.

If you are deploying using ojdeploy:

• You can use the -nodatasources switch, in which case you can set up passwords on Oracle WebLogic Server by either:

  • Creating a global data source.

  • Manually creating application level data sources.

  For more information about ojdeploy, see Deploying from the Command Line.

• If you do not use the -nodatasources switch, you can only set up passwords using application level credential mapping.

22.3.7.5 Preparing an Application for Deployment to a Third Party Server

There may be specific tasks that you have to perform so that your application will run on a third party server.

Deploying to Tomcat:

• Stop and restart the Tomcat server after deployment.

• Make sure that you have the tools.jar library in the Tomcat classpath, located in jdeveloper_install/jdk/lib. This file must be the same version of the JDK being used to run Tomcat. Otherwise, you may encounter problems when running applications in Tomcat.

• The recommended deployment for web applications is tomcat_install/webapps/subdirectory. Set this option in the General page of the WAR File deployment profile.

• The system administrator of the Tomcat application server must assign a context path to your application in the conf/server.xml file:

  <DefaultContext crossContext="true"/> 
  

  See Tomcat system administration documentation for more information.

• You may get the following error message when running a JSP application deployed to Tomcat:

  Only one of the two parameters ... or ... should be defined.
  

  Because Tomcat does not release tags after pooling, subsequent uses of the same tag with incompatible attributes defined will cause this error.

  To avoid the error, you must disable tag pooling in Tomcat:

  1. Open the file tomcat_home/conf/web.xml in a text editor.

  2. Find the following element:

     <init-param>
       <param-name>enablePooling</param-name>
       <param-value>true</param-value>
     </init-param>
     

  Change the value of <param-value> to false

Deploying to WebSphere

WebSphere deployment on Windows does not work when the directory containing the JDeveloper generated EAR contains spaces.

You can directly access the target application server connection in order to pass command line options. For example, you can specify the client JAR which contains the necessary stubs and skeletons on the client side to support RMI-IIOP deployment. These options would overwrite or bypass the server's default settings.

To pass options to target application server connections when deploying:

1. If not already done, create the appropriate deployment profile.

2. In the Applications window, right-click the project, then choose Properties.

3. Select Deployment in the panel on the left of the Project Properties dialog.

4. Select the deployment profile you want to edit, and click Edit.

5. Open the page which corresponds to the target connection type for which you want to pass command options.

6. Edit the page, or click Restore Default to revert to the default settings for the target server.

   For instructions click Help.

7. Click OK when you are finished editing the deployment profile properties.

22.3.8 How to Use Deployment Plans

You can use deployment plans to override deployment values. One reason you might want to do this is to change settings so that an application that has finished testing can be run in a production environment without having to change the deployment profiles.

When an EAR, WAR, or EJB JAR archive configured to use a deployment plan is deployed, both the archive and the deployment plan are sent to the application server. You can use multiple deployment plans in an application. See Understanding WebLogic Server Deployment Plans.

The following is an example of a deployment plan for an EAR called application.ear. Note that the module-name element must contain the name of the deployment profile that it is associated with.

<deployment-plan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.oracle.com/technology/weblogic/10.3/deployment-plan
http://www.oracle.com/technology/weblogic/10.3/deployment-plan/1.0/deployment-plan.xsd" 
xmlns="http://www.oracle.com/technology/weblogic/10.3/deployment-plan">
  <application-name>DeployPlan</application-name>
  <variable-definition>
    <variable>
      <name>SessionDescriptor_timeoutSecs</name>
      <value>888</value>
    </variable>
    <variable>
      <name>SessionDescriptor_invalidationIntervalSecs</name>
      <value>888</value>
    </variable>
    <variable>
      <name>SessionDescriptor_cookieMaxAgeSecs</name>
      <value>888</value>
    </variable>
  </variable-definition>
  <module-override>
    <module-name>application.ear</module-name>
    <module-type>ear</module-type>
    <module-descriptor external="false">
      <root-element>weblogic-application</root-element>
      <uri>META-INF/weblogic-application.xml</uri>
      <variable-assignment>
        <name>SessionDescriptor_timeoutSecs</name>
        <xpath>/weblogic-application/session-descriptor/timeout-secs</xpath>
      </variable-assignment>
      <variable-assignment>
        <name>SessionDescriptor_invalidationIntervalSecs</name>
        <xpath>/weblogic-application/session-descriptor/invalidation-interval-secs</xpath>
      </variable-assignment>
      <variable-assignment>
        <name>SessionDescriptor_cookieMaxAgeSecs</name>
        <xpath>/weblogic-application/session-descriptor/cookie-max-age-secs</xpath>
      </variable-assignment>
    </module-descriptor>
  </module-override>
</deployment-plan>

When an EAR, WAR, or EJB JAR archive configured to use a deployment plan is deployed, both the archive and the deployment plan are sent to the application server. You can use multiple deployment plans in an application.

22.3.8.1 How to Create and Use Deployment Plans

You can create a deployment plan from the New Gallery and edit it in the XML editor.

Once created, a deployment plan can be associated with an EAR, WAR, or EJB JAR archive.

Alternatively, you can generate a deployment plan in Oracle WebLogic Server, then use it in JDeveloper.

To create a deployment plan:

1. In the Applications window, select the project for which you want to create a deployment plan.
2. Choose File > New to open the New Gallery.
3. In the Categories tree, expand General and select Deployment Descriptors. In the Items list, select WebLogic Deployment Descriptor and click OK.
4. In the Select Descriptor page of the Create WebLogic Deployment Descriptor wizard, choose plan.xml.

   If this is the first deployment descriptor you are creating in the application, you can choose Finish to create a deployment plan with the default name of plan.xml.

   If you already have a deployment plan called plan.xml in the application, navigate to the Select Name page and enter a new name for the deployment plan, then click Finish. The deployment plan will be created and added to the project, and it will be opened in an XML editor window.

5. Open the Deployment Profile Properties of the EAR, WAR or EJB JAR.
6. Enter the path to the deployment plan in the Deployment Plan field.

22.3.8.2 How to Generate Deployment Plans

Deployment plans enable you to export an application's configuration for deployment to multiple WebLogic Server environments.

You can create a deployment plan from scratch in JDeveloper.

Alternatively, you can generate a deployment plan which you can then add to your application in JDeveloper and edit it to suit your purposes, described in this topic. There are two ways to do this:

• Deploy the application to a Oracle WebLogic Server, make changes to the application using the Administration Console, and save the resulting deployment plan. You can then copy the deployment plan back into your source in JDeveloper, and if necessary you can modify it.

• Use the weblogic.PlanGenerator command-line tool to generate a deployment plan for an application that uses an EAR. See Generating a Template Deployment Plan using weblogic.PlanGenerator.

To generate a deployment plan using WebLogic Server Administration Console:

1. Deploy the application to Oracle WebLogic Server.

2. Open the WebLogic Server Administration Console.

   The WebLogic Server Administration Console automatically generates (or updates) a valid deployment plan for an application when you interactively change deployment properties for an application that you have installed to the domain. You can use the generated deployment plan to configure the application in subsequent deployments, or you can generate new versions of the deployment plan by repeatedly editing and saving deployment properties.

To use the weblogic.PlanGenerator command-line tool to generate a deployment plan:

1. From the command line, navigate to install/wlserver_10.3/server/bin/ and run either setWLSEnv.sh or setWLSEnv.cmd script, to add the WebLogic Server classes to the CLASSPATH environment variable on your machine, and ensure that the correct JDK binaries are available in your PATH.
2. From the command line, navigate to the location of the EAR file, and run java weblogic.PlanGenerator -plan plan.xml application-name.ear -all.

   The switch -all specifies that the deployment plan is generated containing elements for all possible attributes in your EAR file. If you remove this switch, the generated deployment plan will only contain elements for the existing attributes in your descriptor files.

22.4 Deploying Java Applications

JDeveloper supports deployment of Java applications containing a variety of technologies to a variety of application servers.

This section provides instructions for deploying an application to an executable JAR file on your file system. If you wish to deploy an application containing Java EE technologies, or you wish to deploy to the integrated application server, Oracle WebLogic Server, or another supported application server, be sure to verify that you have performed the necessary configuration and preparation steps as outlined in Connecting and Deploying Java EE Applications to Application Servers.

22.4.1 Deploying to a Java JAR

Applications can be deployed indirectly by choosing an archive file as the deployment target. The archive file can subsequently be installed on a target Java EE application server

JDeveloper has various deployment modes for different applications. However, you may want to quickly and simply deploy your application as a JAR file to your file system.

Note:

Before deploying an executable JAR file you must first create a deployment profile.

To deploy a simple archive in JDeveloper:

1. Select and right-click the project in the Applications window.

2. Choose Deploy deployment profile, where deployment profile is the deployment profile that you created earlier.

3. In the Deployment Action page of the Deploy dialog, choose Deploy to JAR file, and finish the wizard.

You can make your simple archive or Java EE Client Module into an executable JAR file that you can launch with the java command.

Note:

Before deploying an executable JAR file you must first create a deployment profile.

To deploy an executable JAR file:

1. Right-click the project in the Applications window and choose Project Properties.
2. Select the name of the profile in the Deployment section of the Project Properties dialog and click Edit.
3. Click JAR Options in the tree.
4. Select Include Manifest File (META-INF/MANIFEST.MF).
5. In the Main Class field, enter the fully qualified name of the application class that is to be invoked.
6. Click OK.
7. Create the JAR file by deploying the profile to file (see previous section). This creates the JAR file, for example, myapp.jar.
8. Launch the executable JAR file from the command line

   java -jar myapp.jar
   

22.4.2 Deploying to an OSGi Bundle

Applications can be deployed as OSGi bundles which can then be deployed to an OSGi container.

JDeveloper has various deployment modes for different applications. However, you may want to quickly and simply deploy your application as a JAR file to your file system.

Note:

Before deploying an OSGi bundle you must first create a deployment profile. For more information, see How to Create and Edit Deployment Profiles.

To deploy an OSGi bundle in JDeveloper:

1. Select and right-click the project in the Applications window.
2. Choose Deploy > deployment profile, where deployment profile is the OSGi bundle deployment profile that you created earlier.
3. In the Deployment Action page of the Deploy dialog, choose Deploy to OSGi bundle, and finish the wizard.

22.5 Deploying Java EE Applications

JDeveloper supports deployment of Java EE applications containing a variety of technologies to a variety of application servers.

You can use JDeveloper to deploy Java EE applications directly to the standalone application server or create an archive file and use other tools to deploy to the application server.

22.5.1 How to Deploy to the Application Server from JDeveloper

The Java EE Enterprise Archive (EAR) deployment profile provides you with centralized control over the process of application assembly. This assembling task involves selecting which already-configured Java EE deployment profiles to include with the EAR file. You can mix and match any combination of configured WAR, EJB JAR, and/or client JAR profiles in projects within the same application. When you deploy an application to an application server connection, JDeveloper assembles a minimal EAR file which includes the profile combinations and deploys it with the EAR file to the target application server.

To deploy an application as a Java EE Enterprise Archive (EAR File):

1. Create an EAR File deployment profile.
2. Create a connection to the target application server.
3. Right-click the project in Applications window and choose Deploy > deployment profile.
4. In the Deployment Action page of the Deploy dialog, choose one of the deployment options:

   • Deploy to application server connection to package the web module as an EAR file, and deploy it to the application server connection you select or create on the Select Server page of the Deploy dialog.

   • Deploy to EAR file to package the web module as an EAR file and save to the location specified in the EAR deployment profile.

To reopen the EAR deployment profile later to make changes, right-click the application in the Applications window toolbar and choose Application Properties, then select the name of the profile in the Deployment section of the Application Properties dialog and click Edit.

• If you have an existing EAR file, you can use the JDeveloper EAR import facility to import the EAR into any project.

• JAR, WAR, and GAR files to be included in an EAR file must be created before the EAR file is deployed. For the included application's deployment profiles, choose Deploy to JAR file, Deploy to GAR, or Deploy to WAR file in the Deploy dialog to create these subordinate archives.

• The EAR file does not contain passwords so if, for example, you are creating an EAR file to run on Oracle WebLogic Server, you must set up a data source on the server.

22.5.2 How to Deploy a RAR File

Stored in a Resource Adapter Archive (RAR) file, a resource adapter may be deployed on any Java EE server, much like the EAR file of a Java EE application. A RAR file may be contained in an EAR file or it may exist as a separate file

To deploy a resource adapter archive in JDeveloper:

1. Create a deployment profile.

   Note:

   To reopen a project deployment profile later to make changes, right-click the project in the Applications window and choose Project Properties, then select the name of the profile in the Deployment section of the Project Properties dialog and click Edit.

2. Right-click the project in the Applications window, then choose Deploy > deployment profile.
3. In the Deployment Action page of the Deploy dialog, choose Deploy to RAR file.

22.5.3 How to Add a Resource Adapter Archive (RAR) to the EAR

The EAR profile supports Resource Adapter Archive files (RAR or .rar) in a JDeveloper project. A RAR file is typically provided by an Enterprise Intelligence Server (EIS) vendor, similar to a JDBC driver. Java EE developers may need to package a RAR file into their EAR file if their Java EE application makes use of the EIS services supported by the RAR. JDeveloper does not directly support RAR file creation, but RAR files can be assembled using the File Groups feature of a JAR file deployment profile.

The ra.xml file is the deployment descriptor for the RAR file for the J2EE Connector Architecture (JCA). For more information, see:

http://www.oracle.com/technetwork/java/javaee/tech/entapps-138775.html

To add a RAR to an EAR deployment profile:

1. In JDeveloper, add an existing RAR file to a project.
2. Create an EAR deployment profile in the same project as the RAR file.
3. Right-click the project in the Applications window and choose Project Properties.
4. Select the name of the profile in the Deployment section of the Project Properties dialog and click Edit.
5. Click the Application Assembly node to display all the Java EE modules (WAR and EJB JAR) currently available and saved in your project.
6. Select the checkbox next to the RAR (.rar) file that you want to assemble and package with the EAR file.
7. Click OK.
8. Deploy the Java EE EAR.

At deploy-time, the EAR file's application.xml contains a <connector> element which is automatically added to the RAR file.

22.5.4 How to Deploy a Metadata Archive (MAR) File

Metadata Archive (MAR) profiles are application level deployment profiles which are used to package seeded customizations or place base metadata in the MDS repository. In a MAR profile, selections can only be done at the package level, not at the file level.

There are two uses for a MAR profile

• The first use is to create a MAR profile. Once you have created it you can include it in an application's EAR for deployment.

• The second use is to export MAR contents to MDS repository configured for a deployed application in a remote server. This procedure is for applying ADF Library customizations changes to an application that has already been deployed to a remote application server. It is not for the initial packaging of customizations into a MAR that will eventually be a part of an EAR.

For more information, see How to Package and Deploy Customized Applications in Developing Fusion Web Applications with Oracle Application Development Framework.

22.5.5 How to Deploy an Applet as a WAR File

You can deploy web application components including applets as a WAR or EAR file to the target application server.

To deploy an applet as a WAR file:

1. If not already done, configure the applet for deployment.
2. If not already done, create an application server connection.
3. In the Applications window, right-click the project and choose Deploy and select the deployment profile.
4. Deploy to application server connection to create the archive type specified in the deployment profile, and deploy it to the application server connection you select or create on the Select Server page of the Deploy dialog.

   • Deploy to application server connection to create the archive type specified in the deployment profile, and deploy it to the application server connection you select or create on the Select Server page of the Deploy dialog.

   • Deploy to EAR file to deploy the project and any of its dependencies (specified in the deployment profile) to an EAR. JDeveloper puts the EAR file in the default directory specified in the deployment profile.

   • Deploy to WAR file to deploy the project to a WAR. JDeveloper puts the WAR file in the default directory specified in the deployment profile.

   Note:

   The deployed applet files must reside in a separate location from any other web application files you have deployed.

You can test the deployed web application by running it in a browser. For more information, see Testing the Application and Verifying Deployment.

If you encounter problems when deploying a Swing applet (JApplet), for example, the error "Class not found" is displayed, this may indicate that JDeveloper cannot locate the Swing libraries. You may need to force your clients to use the Java SE browser plugin or bundle the Swing libraries for JVMs version 1.1 with your applet.

22.5.6 How to Deploy a Shared Library Archive

Shared Java EE libraries provides an easy way to share one or more different types of Java EE modules among multiple Enterprise Applications. You can deploy shared libraries as JAR files to the application server. See Creating Shared Java EE Libraries and Optional Packages.

To create and deploy a shared library archive:

1. Create a shared library deployment profile, (Shared Library JAR file).
2. Add the libraries to the profile in the Edit JAR Deployment Profile Properties dialog. Choose File Groups, and click New to open the Create File Group dialog, where you define a new file group.
3. Create a connection to the target application server.
4. Right-click the project in Applications window and choose Deploy > shared library deployment profile.
5. On the Deployment Action page of the Deploy shared library dialog, choose Deploy to a Weblogic Application Server and click Finish.

22.5.7 How to Deploy to a Managed Server That Is Down

For successful deployment, the Administration Server for the WebLogic Server domain has to be up as it is handling the deployment process. When you deploy to a server that is down, the deployment log window messages indicate that the server is currently down but the application will be installed when it is brought back up. The log messages will be similar to:

[02:27:21 PM] ----  Deployment started.  ----
   [02:27:21 PM] Target platform is  (Weblogic 10.3).
   [02:27:23 PM] Retrieving existing application information
   [02:27:23 PM] Running dependency analysis...
   [02:27:23 PM] Building...
   [02:27:26 PM] Deploying 2 profiles...
   [02:27:26 PM] Wrote Web Application Module to /scratch/.../jdev/mywork/Application1/Project1/deploy/webapp1.war
   [02:27:26 PM] Wrote Enterprise Application Module to /scratch/.../jdev/mywork/Application1/application1.ear
   [02:27:26 PM] Deploying Application...
   [02:27:27 PM] [Deployer:149195]Operation 'deploy' on application 'application1' has been deferred since   'Server-2' is unavailable
   [02:27:27 PM] [Deployer:149034]An exception occurred for task [Deployer:149026]deploy application application1   on Server-2.: .
   [02:27:27 PM] Application Deployed Successfully.
   [02:27:27 PM] Elapsed time for deployment:  5 seconds
 [02:27:27 PM] ----  Deployment finished.  

One situation that can occur is that deployment appears to succeed, but as the server is brought back up the deployment cannot successfully terminate, for example, because some validation that is part of the deployment process was not performed, or because a library that needs to be present for deployment to be successful is missing. In these cases, when the server is brought back up and deployment resumes, it fails.

You can only deploy an application once to a server that is down. If you attempt to redeploy the same application to the same down server a second time, an error is displayed.

22.6 Post-Deployment Configuration

You can migrate deployed applications from one Oracle WebLogic Server to another.

After you have deployed your application to Oracle WebLogic Server, you can migrate it.

You may need to perform some of the same steps you did for a first time deployment.

In general, to migrate an application to another application server, you would:

• Configure the target application server with the correct database or URL connection information.

• Migrate security information, for example JDBC data sources, from the source to the target.

• Deploy the application to the new server.

22.7 Testing the Application and Verifying Deployment

You can test deployed applications in a browser from the information in JDeveloper’s log window.

After you deploy the application, you can test it from Oracle WebLogic Server.

The deployment log window displays the context root URLs for any Web applications deployed. You can access a deployed web application by entering the application URL in a browser. The URL of the deployed web application appears in the deployment log window, for example:

[03:08:20 PM] The following URL context root(s) were defined and can be used as a starting point to test your application:
[03:08:20 PM] http://12.345.678.912:7101/Project1
[03:08:21 PM] Elapsed time for deployment: 7 seconds
[03:08:21 PM] ---- Deployment finished. ----

You can copy the URL and paste it into a browser to test the deployed web application.

Depending on your browser proxy settings, you may need to specify the full domain name of the host machine. If the servlet engine and the browser used to view a deployed application are on the same machine, you may use localhost for the host name.

22.8 Deploying from the Command Line

Learn how to deploy applications from the command line.

JDeveloper deployment is built around a Design-Time data structure called a profile. A common implementation is an ArchiveProfile that describes the structure of a JAR archive. Deployment profiles can be created as part of a JDeveloper project or workspace. JDeveloper a offers a command-line tool, ojdeploy that allows deployment of ArchiveProfile(s) without invoking the JDeveloper GUI. This is the simplest form of deployment. It has the following characteristics:

ojdeploy can run a deployment locally in-process, or submit to a background server, ojserver. For more information, see Using ojserver.

Before deploying from the command line, you need to run JDeveloper at least once to create a deployment profile for either the application or the project.

Deployment profiles are stored as part of either the application or project properties.

22.8.1 ojdeploy

ojdeploy is available from the command line at jdeveloper_install/jdeveloper/jdev/bin, and the usage is

ojdeploy <commandId>

For additional details, type:

ojdeploy <commandId> -help

Currently the only available commands is deployToArchive (the default). This command deploys to an Archive File.

Usage:

ojdeploy -profile <name> -workspace <jws> [ -project <name> ] [ <options> ]
ojdeploy -buildfile <ojbuild.xml> [ <options> ]
ojdeploy -buildfileschema

You can use the following arguments with ojdeploy.

Table 22-2 Arguments That Can be Used With ojdeploy

Argument	Description
-buildfile	Full path to a build file for batch deploy.
-buildfileschema	Print XML Schema for the build file.
-profile	The name of the Profile to deploy. Deployment profiles can be classified into two broad categories, those that are defined at the application (workspace) level, and those defined at the project level. To deploy an application profile, ojdeploy takes the application location, and the name of the profile. To deploy a project profile it takes an additional -project argument.
-project	Name of the JDeveloper project within the .jws where the profile can be found. If omitted, the profile is assumed to be in the Workspace.
-workspace	Full path to the JDeveloper workspace file(.jws).

You can use the following options with ojdeploy.

Table 22-3 Options Available to Use with ojdeploy

Option	Description
-address	The listen address for ojserver if not using default (localhost:2010). The default parts of the address may be omitted, for example, -address :2001 or -address fasup-pls01
-basedir	Lets Workspace path names be interpreted relatively. The built-in macro ${base.dir} captures the value of -basedir.
-clean	Clean output directories before compiling
-datasources	Deprecated For JEE applications, the -nodatasources option prevents the data-sources.xml file from being updated with connection information found in the IDE. This is ignored for non-JEE applications
-define	Define variables as comma separated name=value pairs
-failonwarning	Prevents the build system from being invoked. This is useful if a workspace or project just needs to be packaged, and not compiled at this time. Adding -clean will delete all files from the project output directory before compiling. Deployment will stop for that profile, if a file or directory could not be deleted.
-forcerewrite	Output file is rewritten even if the contents have not changed in this run of ojdeploy.
-nocompile	Prevents the build system from being invoked. This is useful if a Workspace or Project just needs to be packaged, and not compiled at this time. Adding -clean will delete all files from the Project output directory before compiling. Deployment will stop for that profile, if a file or directory could not be deleted.
-nodatasources	Does not include datasources from IDE.
-nodependents	Tells ojdeploy not to navigate to project and profile dependencies. This means dependent projects will not be automatically compiled and dependent profiles will not be automatically deployed. This is useful in situations where the dependencies between projects and profiles are being calculated externally or when multiple instances of ojdeploy(s) are working on the same set of projects and workspaces.
-ojserver	Runs the deployment job on an ojserver. All paths referenced by the other options should be accessible on the server.
-outputfile	Redirects any JAR files created from the profile. The default is within a \deploy directory inside the Project or Workspace. Automatic file extension: If the -outputfile parameter does not specify a file extension, ojdeploy will figure out the extension by looking at the original file name in the profile.
-project	If specified, tells ojdeploy to look for the profile in the project. Specify the name only, without the path or .jpr extension
-statuslogfile	Creates an XML file that stores a list of all the profiles processed and the status of each. A summary section at the end can be checked to quickly determine the exit status for the entire script.
-stderr	Lets these respective streams be redirected to a file for each profile and project. Macros are allowed in the name or path of the files.
-stdout	Redirect stdout to file
-timeout	Lets the user specify the number of seconds after which deployment of a single profile should be aborted. If the profile is dependent on other profiles that also need to be deployed, they all have to complete within this time.
-updatewebxmlejbrefs	Updates EJB references in web.xml
-workspace	Deployment profiles can be classified into two broad categories, those that are defined at the Application or Workspace level, and those defined at the Project level. To deploy a Workspace-profile, ojdeploy takes the workspace location, and the name of the profile. To deploy a Project-profile, it takes an additional -project argument.

You can use the following built-in Macros with ojdeploy.

Table 22-4 Built-in Macros Available to Use with ojdeploy

Macro	Description
${workspace.name}	Name of workspace (excluding .jws)
${workspace.dir}	Directory containing the .jws file
${project.name}	Name of project (excluding .jpr)
${project.dir}	Directory containing the .jpr file
${profile.name}	Defined name of the profile
${deploy.dir}	Default deploy directory (usually ${project.dir}/deploy or ${workspace.dir}/deploy for project-level and workspace-level profiles respectively)
${base.dir}	Value of the -basedir parameter, or current directory.

Note:

${project.name} and ${project.dir} are only available when a project-level profile is being deployed.

Examples:

Deploy a project-level profile:

ojdeploy -profile webapp1 -workspace /usr/jdoe/Application1/Application1.jws
         -project Project1
ojdeploy -profile webapp1 -workspace Application1/Application1.jws 
         -basedir /usr/jdoe -project Project1

Deploy a workspace-level profile:

ojdeploy -profile earprofile1 -workspace /usr/jdoe/Application1/Application1.jws

Deploy all profiles from all projects of a workspace:

ojdeploy -workspace /usr/jdoe/Application1/Application1.jws 
         -project \* -profile \*

Build in batch mode from a ojbuild file:

ojdeploy -buildfile /usr/jdoe/ojbuild.xml

Build using ojbuild file, pass into, or override default variables in, the build file:

ojdeploy -buildfile /usr/jdoe/ojbuild.xml -define myhome=/usr/jdoe,mytmp=/tmp
ojdeploy -buildfile /usr/jdoe/ojbuild.xml -basedir /usr/jdoe

Build using ojbuild file, set or override parameters in the default section:

ojdeploy -buildfile /usr/jdoe/ojbuild.xml -nocompile

ojdeploy -buildfile /usr/jdoe/ojbuild.xml 
         -outputfile '${workspace.dir}/${profile.name}.jar'
ojdeploy -buildfile /usr/jdoe/ojbuild.xml -define mydir=/tmp 
         -outputfile '${mydir}/${workspace.name}-${profile.name}'

More examples:

ojdeploy -workspace Application1/Application1.jws,Application2/Application2.jws
         -basedir /home/jdoe -profile app*
ojdeploy -buildfile /usr/jdoe/ojbuild.xml 
         -define outdir=/tmp,rel=11.1.1 
         -outputfile'${outdir}/built/${workspace.name}/${rel}/${profile.name}.jar'
ojdeploy -workspace Application1/Application1.jws -basedir /home/jdoe -nocompile
         -outputfile '${base.dir}/${workspace.name}-${profile.name}'
ojdeploy -workspace /usr/jdoe/Application1.jws -project * -profile * 
         -stdout /home/jdoe/stdout/${project.name}.log
ojdeploy -buildfile /usr/jdoe/ojbuild.xml -ojserver

22.8.2 Using ojdeploy from Mac OS X Platforms

If you are using ojdeploy on a on Mac OS X platform, you must set the variable SetSkipJ2SDKCheck in the file jdev_install/jdeveloper/jdev/bin/jdev.conf to true. Your entry should look like this:

SetSkipJ2SDKCheck true

22.8.3 Using ojdeploy

JDeveloper currently supports deployment in Ant scripts. See How to Deploy from the Command Line Using Ant .

Deploying from the command line using ojdeploy is especially useful where you need to deploy existing projects or applications using a batch file or other script.

22.8.3.1 How to Override Without Editing a Build Script

To pass in macro values or override the ones defined in a build script, use the -define option to supply a new value:

ojdeploy -buildfile /home/jdoe/ojbuild.xml -define "mycustomdir=/tmp"

This adds the mycustomdir variable to the <defaults> section of the build script, or replace it if it already is defined with the value /tmp.

To pass in parameter values or override the ones defined in a build script, use the appropriate parameter option, for example:

ojdeploy -buildfile /home/jdoe/ojbuild.xml -nocompile -nodatasources

This adds the -nocompile and -nodatasources parameters to the default section of the build file.

22.8.3.2 How to Deploy Multiple Profiles from the Command Line

Command-line deployment supports deployment of multiple applications in a single invocation. If more complex control is required, ojdeploy can take an XML build script and process it, running all deploy tasks found in it. Macros and wild cards can be used both in command-line and batch mode. Macros can be strung together or nested.

Each profile to be deployed is qualified by an application and a project. In addition each profile's output can be directed to a different output file/location. Further to this, the calling script assumes no knowledge of the projects within am application, only deploying all or a subset of them matching a criteria. The command-line syntax for specifying such inputs and criteria can quickly become cumbersome and inflexible.

A build file can be passed to ojdeploy. The build file will contain multiple <deploy> tasks, along with a shared <defaults> section which allows for setting up an environment. Each deploy-task specifies the type of deployment (the set mentioned before) and customizes any defaults as required. Each task also allows wild cards as applicable within parameter arguments that apply to the scope of that task. A pre-processor will parse the build file and pass it to ojdeploy, expanding wild cards and substituting variables as necessary.

The build file approach has the following advantages over the command-line syntax:

• It lets more parameters be added to ojdeploy without forcing the implementor for that parameter to be aware of a batch-build concept.

• It keeps the command-line syntax simple, for the degenerate case.

• It allows parameters to be dynamically evaluated based on the current context, and access to a predefined list of pre-processor macros. For example, OutputFile location may be specified as c:\temp\${profile.name} where the macro ${profile.name} is added automatically.

A sample build file is shown below. To invoke all of these deploy actions, the command-line would be ojdeploy ojdeploy-build.xml. The file is processed from top to bottom.

<?xml version="1.0" encoding="US-ASCII" ?>
<ojdeploy-build basedir="/usr/jdoe/">
  <!-- Defines default parameters for all deploy tasks.
       Also defines some variables strictly for use within this file
       in macros
  -->
  <defaults>
    <parameter name="profile" value="*"/>
    <parameter name="nocompile" />
    <-- define a macro -->
    <variable name="customdir" value="/var/projects/fin/"/>
  </defaults>
  <!-- Select all .jws files in location ${customdir} called absoluteFile1.jws, absoluteFile2.jws.
       Open all projects.
       Deploy profiles p1, p2, p3 in each project, in each workspace.
  -->
  <deploy>
    <parameter name="workspace" value="${customdir}/absoluteFile1.jws,${customdir}/absoluteFile2.jws"/>
    <parameter name="project" value="*"/>
    <-- Override default profile parameter -->
    <parameter name="profile" value="p1,p2,p3"/>
  </deploy>
  <!--
    Open relativeFile1.jws in the base directory
    Open all projects.
    Deploy all profiles (default for "profile" parameter is "*")
  -->
  <deploy>
    <parameter name="workspace" value="relativeFile1.jws"/>
    <parameter name="project" value="*"/>
  </deploy>
  <!--
    Open relativeFile2.jws in base directory.
    Open all Projects
    Deploy profiles matching the patter "web*"
  -->
  <deploy>
    <parameter name="workspace" value="relativeFile2.jws"/>
    <parameter name="project" value="*"/>
    <parameter name="profile" value="web*"/>
  </deploy>
</ojdeploy-build>

22.8.3.3 How to Use Wildcard Samples

Project and profile names can be specified as "*" or "name*" or "name1,name2,name3,..." or any combination of these. Application names need to be enumerated, so "*" is not allowed in application names, but application names can be specified as "application1" or "application1,application2,application3".

For example:

• adf* (Profile)

• View* (Project)

• *Controller (All Controller Projects)

An example of using wild cards with an application:

<ojdeploy-build basedir= "/home/jdoe" >
  <deploy>
    <parameter name= "workspace" value= "Application1.jws,Application2.jws" />
    <!-- above pattern gets /home/jdoe/Application1.jws and /home/jdoe/Application2.jws -->
    . . .
  </deploy>
/ojdeploy-build>

22.8.3.4 How to Create a Log File for Batch Deployment

The -statuslogfile parameter lets the user create a build summary for the entire deployment batch. An absolute path should be specified without macros.

The log file contains a list of the deployment tasks processed and the status from each task in XML format. The status will be either SUCCESS or FAILED and includes an exitcode attribute. Possible values for exitcode are:

• 0 - Success

• 1 - Fatal error (NPE, OutOfMemory, etc.)

• 2 - JDeveloper configuration error (missing extensions, etc.)

• 4 - Deployment Error (compilation, deployment exception, etc.) All exit codes are bitwise OR-ed.

A combined status is available in a summary section at the end of each log.

The following is an example of batch deployment log output.

<?xml version="1.0"?>
 <ojdeploy-log>
  <deploy-task>
   <target>
    <profile>webapp1</profile>
    <workspace>/scratch/jdoe/jdev/mywork/Application3/Application3.jws</workspace>
    <project>Project1.jpr</project>
   </target>
   <exception msg="**** One or more compilation errors prevented deployment from continuing.">
    oracle.jdeveloper.deploy.DeployException: **** One or more compilation errors prevented deployment from continuing.
    at oracle.jdevimpl.deploy.common.ModulePackagerImpl.compileDependents(ModulePackagerImpl.java:143)
    at oracle.jdeveloper.deploy.common.ModulePackager.compile(ModulePackager.java:65)
    at oracle.jdeveloper.deploy.common.ModulePackager.prepareImpl(ModulePackager.java:52)
    at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69)
    at oracle.jdevimpl.deploy.fwk.WrappedDeployer.prepareImpl(WrappedDeployer.java:32)
    at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69)
    at oracle.jdevimpl.deploy.fwk.WrappedDeployer.prepareImpl(WrappedDeployer.java:32)
    at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69)
    at oracle.jdevimpl.deploy.fwk.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:411)
    at oracle.jdevimpl.deploy.fwk.DeploymentManagerImpl$1.run(DeploymentManagerImpl.java:281)
 
   </exception>
   <status exitcode="4">FAILED</status>
  </deploy-task>
  <deploy-task>
  <target>
   <profile>archive1</profile>
   <workspace>/scratch/jdoe/jdev/mywork/Application3/Application3.jws</workspace>
   <project>Project1.jpr</project>
  </target>
  <exception msg="**** One or more compilation errors prevented deployment from continuing.">
    oracle.jdeveloper.deploy.DeployException: **** One or more compilation errors prevented deployment from continuing.
    at oracle.jdevimpl.deploy.common.ModulePackagerImpl.compileDependents(ModulePackagerImpl.java:143)
    at oracle.jdeveloper.deploy.common.ModulePackager.compile(ModulePackager.java:65)
    at oracle.jdeveloper.deploy.common.ModulePackager.prepareImpl(ModulePackager.java:52)
    at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69)
    at oracle.jdevimpl.deploy.fwk.WrappedDeployer.prepareImpl(WrappedDeployer.java:32)
    at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69)
    at oracle.jdevimpl.deploy.fwk.WrappedDeployer.prepareImpl(WrappedDeployer.java:32)
    at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69)
    at oracle.jdevimpl.deploy.fwk.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:411)
   at oracle.jdevimpl.deploy.fwk.DeploymentManagerImpl$1.run(DeploymentManagerImpl.java:281)
 
  </exception>
  <status exitcode="4">FAILED</status>
 </deploy-task>
 <deploy-task>
  <target>
   <profile>ejb1</profile>
   <workspace>/scratch/jdoe/jdev/mywork/Application3/Application3.jws</workspace>
   <project>Project3.jpr</project>
  </target>
 <status exitcode="0">SUCCESS</status>
 </deploy-task>
 <summary>
 <start-time>2007-12-19 12:10:42 PST</start-time>
 <end-time>2007-12-19 12:10:45 PST</end-time>
 <total-tasks>3</total-tasks>
 <failures>2</failures>
 <status exitcode="4">FAILED</status>
 </summary>
 </ojdeploy-log>

22.8.3.5 Timeouts

The -timeout parameter can be used for terminating runaway deployments. It specifies an upper limit on how much time deployment can take.

Timeout is for each Profile, not for the entire batch.

22.8.4 How to Deploy from the Command Line Using Ant

JDeveloper deployment is built around deployment profiles. A common implementation is an ArchiveProfile that describes the structure of a JAR archive.

Deployment profiles can be created as part of a project or application. With ojdeploy you can deploy ArchiveProfile(s) without invoking the JDeveloper IDE.

Command line deployment requires a JDeveloper installation. but this installation is invoked in 'headless mode', not displaying the JDeveloper IDE, loading all extensions defined for headless mode. This form of deployment can read JDeveloper applications and projects and their meta-data.

Ant scripts to invoke command line deployment must be created manually. The resulting deployed archive depends on the version of JDeveloper used, and which extensions are enabled when command line deployment is invoked.

Note:

It is a best practice to generate an .ear file from JDeveloper for the application. The .ear file will be generated with all the right class dependencies required to deploy it. Deploying with Ant by referring to an application directly (without generating an .ear file) may require dependencies for the classes and JAR files to be resolved manually.

The ojdeploy task is an extension of the Ant <exec> task, so any valid attributes of that task can be used with ojdeploy, such asarg and failonerror.

For example, to have a deployment stop when it reaches an error, add failonerror="true".

For more information see the Exec tasks section of the Apache Ant Manual at http://ant.apache.org/manual.

22.8.4.1 How to Generate an Ant Build Script

To make it easier to create an Ant build script for command line deployment, you can generate an Ant script from JDeveloper.

1. In the Projects window select a project or an application, and select File > New > From Gallery. In the General category, choose Ant. In the Items pane select the Buildfile type, then click OK.

   Figure 22-4 Selecting Buildfile Type

   
   Description of "Figure 22-4 Selecting Buildfile Type"
2. Complete the Create Buildfile from Project dialog and click OK. To invoke ojdeploy from this script enable Include Packaging Tasks.

   Figure 22-5 Provide File Details

   
   Description of "Figure 22-5 Provide File Details"

   The generated file has the structure shown in the build.properties file in About The build.properties File.

22.8.4.2 About The build.xml File

The build.properties file, which is generated along with build.xml, defines the additional variables needed for command line deployment.

The following is an example of build.xml.

#Fri Feb 15 10:45:22 PST 2008
   #Sun Feb 24 18:47:36 PST 2008
   javac.nowarn=off
   javac.debug=on
   build.compiler=oracle.ojc.ant.taskdefs.OjcAdapter
   output.dir=classes
   oracle.home=../../oracle/
   javac.deprecation=off
   oracle.jdeveloper.ant.library=/scratch/jdoe/oracle/jdev//lib/ant-jdeveloper.jar
   oracle.jdeveloper.deploy.dir=/scratch/jdoe/Application7/Project1/deploy/
   oracle.jdeveloper.ojdeploy.path=/scratch/jdoe/oracle/jdev//bin/ojdeploy
   oracle.jdeveloper.workspace.path=/scratch/jdoe/Application7/Application7.jws
   oracle.jdeveloper.project.name=Project1
   oracle.jdeveloper.deploy.profile.name=*
   oracle.jdeveloper.deploy.outputfile=/scratch/jdoe/Application

22.8.4.3 About The build.properties File

The Ant build script can be run outside of JDeveloper by simply changing to the directory containing build.xml and running Ant. It can also be run from within JDeveloper, by right-clicking on the build.xml node in the Applications window and selecting the "all" or the "deploy" targets.

Note:

By default, the command line deployment task has the nocompile option enabled as the task has dependency on the compile task. If this dependency is removed then the nocompile option can be removed.

It is a best practice to generate an .ear file from JDeveloper for the application. The .ear file will be generated with all the right class dependencies required to deploy it. Deploying with Ant by referring to an application directly without generating an .ear file may require that dependencies for the classes and jars files must be resolved manually.

The following is an example of the build.properties file.

Buildfile: /scratch/jdoe/Application7/Project1/build1.xml 
 
init: 
 
compile: 
deploy:
 [ora:ojdeploy]
 [ora:ojdeploy] Oracle JDeveloper Deploy 11.1.1.0.0
 [ora:ojdeploy] Copyright (c) 2008, Oracle. All rights reserved.
 [ora:ojdeploy]
 [ora:ojdeploy] ----build file----
 [ora:ojdeploy] <?xml version = '1.0' standalone = 'yes'?>
 [ora:ojdeploy] <ojdeploy-build>
 [ora:ojdeploy] <deploy>
 [ora:ojdeploy] <parameter name="workspace" 
value="/scratch/jdoe/Application7/Application7.jws"/>
 [ora:ojdeploy] <parameter name="project" value="Project1"/>
 [ora:ojdeploy] <parameter name="profile" value="*"/>
 [ora:ojdeploy] <parameter name="nocompile" value="true"/>
 [ora:ojdeploy] <parameter name="outputfile" 
value="/scratch/jdoe/Application7/Project1/deploy/${profile.name}"/>
 [ora:ojdeploy] </deploy>
 [ora:ojdeploy] <defaults>
 [ora:ojdeploy] <parameter name="buildfile" 
value="/scratch/jdoe/Application7/Project1/deploy/ojdeploy-build.xml"/>
 [ora:ojdeploy] <parameter name="statuslogfile" 
value="/scratch/jdoe/Application7/Project1/deploy/ojdeploy-statuslog.xml"/>
 [ora:ojdeploy] </defaults>
 [ora:ojdeploy] </ojdeploy-build>
 [ora:ojdeploy] ------------------
 [ora:ojdeploy] ---- Deployment started. ---- Feb 24, 2008 6:49:51 PM
 [ora:ojdeploy] Target platform is (WebLogic 10.3).
 [ora:ojdeploy] Running dependency analysis...
 [ora:ojdeploy] Wrote JAR file to 
/scratch/jdoe/Application7/Project1/deploy/archive1.jar
 [ora:ojdeploy] Elapsed time for deployment: less than one second
 [ora:ojdeploy] ---- Deployment finished. ---- Feb 24, 2008 6:49:51 PM
 [ora:ojdeploy] ---- Deployment started. ---- Feb 24, 2008 6:49:51 PM
 [ora:ojdeploy] Target platform is (Java Enterprise Edition 1.5).
 [ora:ojdeploy] Running dependency analysis...
 [ora:ojdeploy] Wrote WAR file to 
/scratch/jdoe/Application7/Project1/deploy/WindowMobile.war
 [ora:ojdeploy] Elapsed time for deployment: less than one second
 [ora:ojdeploy] ---- Deployment finished. ---- Feb 24, 2008 6:49:52 PM
 [ora:ojdeploy] Status summary written to 
/scratch/jdoe/Application7/Project1/deploy/ojdeploy-statuslog.xml
 
BUILD SUCCESSFUL
 Total time: 19 seconds

22.8.4.4 ojdeploy for Extension Developers

The ojdeploy command offers a framework that allowed extensions to plug into the ojdeploy process. Prior to the new framework, ojdeploy only allowed deployment to archives. The new framework is designed to handle the creation and execution of any DeployCommand implementation. The framework allows, for example, any extension to define ojdeploy support for its DeployCommand.

The new framework allows extensions the freedom to:

• Define their own OJDeploy arguments and parsing rules.

• Define their own Command Parser and Model (optional).

• Define their own argument expansion and wildcard logic via ContextIterators. (optional)

• Control the exact makeup of their DeployCommand Context.

• Control the creation and setup of their DeployCommand instances.

The framework is designed to allow a great deal of flexibility while offering extension writers a mechanism that is easy to use because it provides many built-in components; for example, AbstractCommandSupport and AbstractContextIterator.

Table 22-5 Class Lexicon

Class Name	Description
Arguments	Represents command line arguments passed into the ojdeploy process. Note that Buildfiles parameters/variables are also converted into Arguments for processing.
BuildScript	A BuildScript represents the buildfile that is the input of the OJDeploy process. Note that a BuildScript can be created from a buildfile or by parsing command line arguments. Regardless, a BuildScript is always created during the OJDeploy process.
OJBuildScriptSupport	This class converts the BuildScript into an ojdeploycommanditerator. As shown in the sequence diagram below, this class controls the OJCommandSupport creation, parsing of arguments and the creation of OJContextIterators.
OJCommandSupport	This class is used to support the proper creation of a given DeployCommand. For example, the DeployToArchiveCommandSupport is one implementation that allows Deployment of Profiles to an archive file. This is where the bulk of the logic will be implemented for your own ojdeploy command extension. You can refer to the following HOW To section for instructions on How to write your own OJCommandSupport implementation.
Context	An IDE Context. The context is critical because it is used in order to create any DeployCommand instance via the DeployCommandFactory. As an ojdeploy extension, you will be required to construct the Context necessary to instantiate your DeployCommand instances.
OJContextIterator	An Iterator of Contexts. Note that various Context Iterators have been pre-built for you to use. For example, the ojdeploy framework includes iterators that will populate Context instances based on a given Workspace (WorkspaceContextIterator), Project (ProjectContextIterator) and Profile (ProfileContextIterator). You likely will not need to create your own ContextIterator but in the event that you do, the framework also includes an AbstractContextIterator that you can extend for that purpose (more on this in the following section on How to write your own OJContextIterator.).
DeployCommand	The entire purpose of the ojdeploy process is to create DeployCommand instances and run them. A DeployCommand is an extension of the IDE Command.
DeployService	The DeployService is invoked by the ojdeploy process to control creation and execution of a DeployCommand in the ojdeploy process. It is in effect the client of the OJDeploy Framework API as shown in the sequence diagram below.
OJCommandModel	An OJCommandModel is an extension to the IDE CommandModel. It holds the arguments parsed into the OJCommandParser.
OJCommandParser	The OJCommandParser is used to parse Arguments and create the OJCommandModel.
OJCommand	Not to be confused with the DeployCommand, the OJCommand is a simple class which simply holds the CommandID (for example, "Deployment.DeployToFile") and Command Label (DeployToArchive). The CommandID is used by the DeployCommandFactory in order to create the DeployCommand. The Command Label is what is used as the DeployCommand identifier on the command line or buildFile. The Command Label is simply a user friendly representation that corresponds to the CommandID. There is therefore a one to one relationship between the two.
OJDeployCommandIterator	The OJDeployCommandIterator is used to iterate all DeployCommand instances of a given BuildScript. Note that the OJDeployCommandIterator in conjunction with the OJContextIterators allow for lazy loading of all DeployCommand context objects (Workspace, Project, Profile etc) and also releases those objects automatically after each command execution for proper resource management during the ojdeploy process.

Figure 22-6 Sequence Diagram

Description of "Figure 22-6 Sequence Diagram"

Current Limitations

• To recreate a deployed module with ojdeploy just as if it were being deployed from within the IDE in GUI mode, the exact same JDeveloper installation should be used. A change in the Jdeveloper installation means a possible change in the extensions that are loaded, or their versions, and thus the end result may also change.

• Startup time of ojdeploy is dependant on startup time for a headless JDeveloper. All the extensions that are registered for this mode, need to be initialized. This time could be shortened by each Extension optimizing itself for the headless mode. For large builds, the -ojserver option can submit a deploy job to a server running in the background. See OJServer

Using the headless Attribute

ojdeploy runs JDeveloper in headless (non-GUI) mode, which enables all the various extensions that support this mode.

• To ensure IDE Addins (oracle.ide.Addin) are loaded when running in headless mode they should be marked with the "headless=true" tag. Addins that are not marked as such, should not be referred to from these headless Addins.

  During Addin.initialize() all the IDE contexts are available, including the current Active Workspace and Project.

• All Deployment Toolkits provided by the extension that need to run in ojdeploy also need to be marked with the "headless=true" attribute

22.8.5 Using ojserver

ojserver is a headless version of JDeveloper that runs in server mode, listening to remote client requests. Clients and submit service requests to the server using RMI. ojserver's main purpose is to reduce the startup time incurred when using command-line tools in batch scripts that run JDeveloper in headless mode. ojserver can be found in the oracle/jdeveloper/jdev/bin directory.

To see the usage, parameters, options, and examples for ojserver, at the command line for jdeveloper_install/jdeveloper/jdev/bin type ojserver.

ojdeploy can run a deployment locally in-process, or submit to a background OJServer using the -ojserver option. When using -ojserver, ojdeploy blocks till the deployment is complete, and exit codes are set depending on how deployment fared on the server.

All the options for local deployment are also available when running on ojserver, however, if any absolute paths are being used, they have to be accessible on the server.

22.9 Deploying Using Java Web Start

Learn how to use Java Web Start to deploy Java applications so that they can be launched from an internet browser.

Java Web Start is included in the Java Runtime Environment (JRE) as part of Java SE 6 and later: http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html.

JDeveloper supports the creation of the XML-based JNLP (Java Network Launching Protocol) definition upon which the Java Web Start technology is based. Java Web Start lets you maintain Java client applications and applets on the web server, which users download and run on their client machines.With the Create Java Web Start-Enabled wizard in JDeveloper, you can set up applications and applets to be maintained on the web server, but downloaded and run on client machines.

Note:

Starting with Java SE 7 Update 21 in April 2013 all Java Applets and Web Start Applications are encouraged to be signed with a trusted certificate. And starting with 7u25, all files must be added to JARs prior to signing. For more details, refer to the Java web site at http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html.

The process of developing a Java Web Start application can be summarized as:

1. Develop the Java application.

2. Simulate the user's experience of running the application with Java Web Start within the JDeveloper IDE.

3. Use the JDeveloper Java EE Web deployment process to move the production application to the web server.

Note:

To launch applications and applets with Java Web Start in JDeveloper, you must download and install the Java Web Start software. Users of your application or applet will also be required to install the software on their machines.

For more information on Java Web Start and to download the Java Web Start software, see: http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html.

22.9.1 Purpose of the Java Web Start Technology

Although Java Web Start and applets may appear to be similar technologies, there are several differences:

• Unlike the applet approach to deploying web-centric Java applications, Java Web Start does not rely on the web browser to perform the downloading of the application JAR files. Instead, Java Web Start downloads the application resources after the Java Web Start JNLP descriptor is downloaded through the web browser. The JNLP descriptor causes Java Web Start to launch and perform the actual downloading.

• While users of the application may experience the applet identically in Java Web Start, they are not tied to the web browser as they would be with applets. Once the application is running, the web browser can be closed, and the application continues to run in Java Web Start.

With the Java Web Start software installed once on the client machine, the application user can run applications and applets simply by clicking on a web page link. If the application is not present on their computer, Java Web Start automatically downloads all necessary files from the web server where the application libraries reside. It then caches the files on the client computer so the application is always ready to be relaunched anytime either from an icon on your desktop or from the browser link. The most current version of the application is always presented to the user since Java Web Start performs updates as needed.

22.9.1.1 Files Generated by the Create Java Web Start-Enabled Wizard

Application users can use Java Web Start to run applications and applets on client machines, while you maintain the application on the web server. To support Java Web Start and web server downloading, the Create Java Web Start-Enabled wizard generates these files:

• The Java Network Launching Protocol (JNLP) definition required by Java Web Start to download and launch the application. The .jnlp file describes the archive files and whether this instance includes an applet or an application.

• An HTML file that contains the URL to initiate the downloading from the web server to the client. Although HMTL file creation is optional, it is highly recommended unless you intend to create the file manually.

Users can use Java Web Start to run applications and applets on client machines, while you maintain the application on the web server. To support Java Web Start and web server downloading, the Create Java Web Start-Enabled wizard generates these files:

22.9.1.2 Role of the Web Server in JDeveloper

JDeveloper provides an Integrated WebLogic Server web server. You can use it to simulate the process of deploying the Web Application Archive and downloading for use with Java Web Start. JDeveloper follows the J2SE deployment profile conventions for archiving components that run on the client machine (simple archive) and components that are deployed to the web server (Web Application Archive).

How to complete the Java Web Start setup:

1. Create a simple Java Archive (.jar) file that contains the application source files to be downloaded and run on the client machine.

2. Launch the Create Java Web Start-Enabled wizard in JDeveloper to create the HTML and JNLP files that will enable the application or applet to be downloaded and run on the client machine.

3. .Create a Web Application Archive (.war) file which you deploy to the web server. It will contain the contents of the public_html directory in your JDeveloper mywork folder, including the JAR, HTML and JNLP files.

Note:

You will not be required to deploy the application to use the JDeveloper-embedded web server. JDeveloper provides a default web.xml definition to locate the contents of the public_html directory in your JDeveloper mywork folder.

Once you have set up the web server, you can launch the Java Web Start software in JDeveloper using the generated .html file. Java Web Start relies on your web browser to download the components identified by the .jnlp file. Another definition in the .jnlp file determines whether it will run as an application or a secure applet. Once you have launched Java Web Start and the downloading is complete, you can close your web browser and continue to run the application or applet.

22.9.2 How to Create a Java Web Start File

A Java Network Launching Protocol definition file, application-name.jnlp, is automatically created when you use the Create Java Web Start-Enabled wizard to create Java clients to download and run Java applications and applets on client machines. However, if you want to control the contents of the application-name.jnlp, you can manually create your own file to use.

Note:

If this item appears grayed out, this indicates that there is an application-name.jnlp file already created in the project. You can have only one of each deployment descriptor type per project.

To manually create a Java Web Start (.jnlp) file:

1. In the Categories tree, expand General and select Deployment Descriptors. In the Items list, double-click Java Web Start (JNLP) Files.
2. If the category or item is not found, make sure the correct project is selected, and choose All Technologies in the Filter By dropdown list.
3. Click OK.
4. The newly created file opens in the Code Editor. Edit this file to add the configuration settings as appropriate.

For more information on Java Web Start, see http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html.

22.9.3 How to Create a Java Client Web Archive for Java Web Start

You can use the JDeveloper Java EE web deployment process to set up the server before downloading and running the application using Java Web Start.

Once the application resides on the web server, it becomes very easy to maintain. Java Web Start takes care of identifying and downloading application updates each time the user runs the application.

To create Java client applications for deployment to the web server:

1. Create a simple JAR archive of your Java client application.
2. Create a Web Start JNLP Definition for Java Clients to generate the JNLP file and HTML file for use with Java Web Start.
3. In the Applications window, select the project in which you want to create the WAR deployment profile.
4. Choose File > New to open the New Gallery.
5. In the Categories tree, expand General and select Deployment Profiles. In the Items list, double-click WAR File.
6. If the category or item is not found, make sure the correct project is selected, and choose All Technologies in the Filter By dropdown list. Enter the name of the new deployment profile then click OK.
7. The WAR Deployment Profile Properties panel displays. Configure the settings for each page as appropriate. Click OK when you have finished defining the properties.

   The newly created web.xml deployment descriptor appear in the Applications window below the specified project.

8. Deploy the Java Client Web Archive for Java Web Start.
9. (Optional) If you want to edit the web.xml deployment descriptor, right-click the web.xml file in the Applications window and choose Open.
10. (Optional) To reopen a project deployment profile later to make changes, right-click the project in the Applications window and choose Project Properties, then select the name of the profile in the Deployment section of the Project Properties dialog and click Edit.

When you are ready to deploy the resulting WAR or EAR to the target application server, make sure to create an application server connection.

Note:

The web module is deployed to the target deployment directory.

Make sure that the web application deployment descriptor is located inside the Web Application Archive (WAR) file WEB-INF/web.xml.

22.9.4 How to Create a Java Web Start JNLP Definition for Java Clients

You use the Create Java Web Start-Enabled wizard to create the XML-based JNLP (Java Network Launching Protocol) definition file that the Java Web Start software uses to download and run Java applications and applets on client machines.

Note:

You must download and install the Java Web Start software to launch applications and applets with Java Web Start in JDeveloper. Users of your application or applet will also be required to install the software on their machines. See

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html

The application or applet must be delivered in a set of JAR files and all application resources, such as images, configuration files and native libraries, must be included in the JAR files. The resources must be looked up using the ClassLoader getResource or another method. Java Web Start only transfers JAR files from the web server to the client. for additional information, see http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html

The wizard adds a JNLP file and (optionally) an HTML file to your project. Java Web Start will use these generated files to determine what application source to download from the web server:

• The Java Network Launching Protocol (JNLP) definition is required by Java Web Start to download and launch the application. The .jnlp file describes the archive files and whether this instance includes an applet or an application.

• An HTML file. Although HMTL file creation is optional, it is highly recommended unless you intend to create the file manually. The HTML file contains the URL to initiate the downloading from the web server to the client.

Before you launch the Create Java Web Start-Enabled wizard to create the JNLP and HTML files, you must create a simple archive (JAR) file for it. You must also know in which class the main function can be found, as you will be asked to specify this.

To create the JNLP definition for your application or applet:

1. In the Applications window, select the project in which you want to generate a JNLP definition. Choose File > New to open the New Gallery.
2. In the Categories tree, expand Client Tier and select Swing/AWT. In the Items list, double-click Java Web Start (JNLP) Files to open the Create Java Web Start-Enabled wizard.

   Click Next in the Welcome page.

3. In the Application Information page, enter the file name, the name and location of the JAR file that you created, and the class that you want to use to run your application.
4. For detailed help in using the Create Java Web Start-Enabled wizard, press F1 or click Help from within the wizard.
5. Check Create Homepage to create the optional HTML file. Click Next after specifying the desired options.
6. In the Web Start page, specify information to document the JNLP file. Complete the wizard and click Finish.

You can also use a JSP file or servlet with Java Web Start; however, you will have to manually configure the file and change the content type. Here is an example JNLP with contentType = application/x-java-jnlp-file, specified in the first line:

<%@ page contentType="application/x-java-jnlp-file" %>
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="http://192.168.1.102:8888" href="jnlpfile.jnlp">
<information>
<title>Test</title>
<vendor>Oracle</vendor>
<homepage href="Test.html"/>
<description>Encryption Tool</description>
<icon href="images/frontpage.gif"/>
<offline-allowed/>
</information>
<security><all-permissions/></security>
<resources>
<j2se version="1.3"/>
<jar href="/apps/archive1.jar" main="true" download="eager" />
</resources>
<application-desc main-class="oracle.Ide">
</application-desc>
</jnlp>

22.9.5 How to Deploy a Java Client Web Application Archive for Java Web Start

You can use the JDeveloper simple Java EE web deployment process to set up the web server before downloading and running the application using Java Web Start.

Once the application resides on the web server, it becomes very easy to maintain. Java Web Start takes care of identifying and downloading application updates each time the user runs the application.

To deploy Java client applications to the web server:

1. If not already done, create a Java Client Web Archive for Java Web Start.
2. If not already done, create an application server connection.
3. Create a simple JAR archive of your Java client application.
4. Create a Web Start JNLP Definition for Java Clients to generate the JNLP file and HTML file for use with Java Web Start.
5. Select and right-click project in the Applications window. The context menu displays these deployment options:

   • Deploy > deployment profile > to most-recent to deploy the project to the application server or archive file you previously chose.

   • Deploy > deployment profile > to application server connection creates the archive type specified in the deployment profile, and deploys it to the selected application server connection.

   • Deploy > deployment profile > to EAR file to deploy the project and any of its dependencies (specified in the deployment profile) to an EAR. JDeveloper puts the EAR file in the default directory specified in the deployment profile.

   • Deploy > deployment profile to > WAR file the web module is packaged as a WAR file and saved to the local directory you specified earlier in the deployment profile settings.

6. (Optional) If you want to edit the web.xml deployment descriptor, right-click the web.xml file in the Applications window and choose Open.
7. (Optional) To reopen a project deployment profile later to make changes, right-click the project in the Applications window and choose Project Properties, then select the name of the profile in the Deployment section of the Project Properties dialog and click Edit.

Note:

Make sure that the web application deployment descriptor is located inside the Web Application Archive (WAR) file, WEB-INF/web.xml.

22.10 Deploying Using Weblogic SCA Spring

The Oracle JDeveloper Weblogic SCA Spring Extension provides integrated support for WebLogic SCA and for the open-source Spring framework.

The extension allows you to create:

• WebLogic SCA enabled projects that can be deployed as a JAR file which can then be included in an EAR file for deployment, or as a WAR file.

• Spring framework projects.

22.10.1 About WebLogic SCA

The extension provides support for creating WebLogic SCA applications in JDeveloper and deploying them in Oracle WebLogic Server. WebLogic SCA is based on a subset of the OASIS Service Component Architecture Spring Component Implementation Specification. See https://www.oasis-open.org.

Service Component Architecture (SCA) provides a model for building enterprise applications and systems as modular business services that can be integrated and reused. WebLogic SCA provides support for developing and deploying SCA applications using POJOs (Plain Old Java Objects). In SCA, the implementation of a component and its communication are separate. In WebLogic SCA, you can write Java applications using POJOs and, through the different protocols available, expose components as SCA services and access them via references. You do this using SCA semantics configured in a Spring application context. In SCA terms, a WebLogic Spring SCA application is a collection of POJOs plus a Spring SCA context file that declares SCA services and references with the appropriate bindings. WebLogic Spring SCA applications can be used without modification as components in Oracle SOA composites.

In WebLogic Server, WebLogic Spring SCA applications run in the WebLogic SCA Runtime. The runtime must be deployed to WebLogic Server as a shared Web application library before applications can be deployed to it. For more, see How to Deploy WebLogic SCA Applications to Integrated WebLogic Server.

See WebLogic Spring SCA Applications .

22.10.2 About Spring

Spring is an open-source framework that simplifies development of enterprise Java applications. The Spring framework includes models for various layers and functionality areas of Java applications. It focuses on using POJOs, leverages inversion of control concepts and dependency injection, and implements aspect oriented programming.

The Weblogic SCA Spring Extension provides integrated support for creating open source Spring projects in JDeveloper that can be used in Java EE applications. It adds the Spring JAR files as a library to JDeveloper, and it adds a wizard and editing features for creating Spring Bean configuration files. The extension creates: Adds the Spring JAR files as the Spring 2.5 library to JDeveloper. Adds a wizard for creating Spring Bean configuration files Registers the relevant XSDs and DTDs with the IDE to provide a productive editing experience for Spring definitions.

For more information about Spring, see Developing and Administering Spring Applications for Oracle WebLogic Server.

22.10.3 Installing the Weblogic SCA Spring Extension

To use the Oracle JDeveloper Weblogic SCA Spring Extension, you must download it and install it. The extension adds the following to JDeveloper:

• The Spring category to the Business Tier in the New Gallery. The options for creating the Spring Bean Configuration file and the WebLogic SCA Configurations are available here.

• The Spring 2.5 library is added to JDeveloper, along with the JAR files of the Spring framework and support for WebLogic SCA.

22.10.4 Using Oracle WebLogic SCA

You can use the Weblogic SCA Spring Extension to create WebLogic SCA enabled projects that can be deployed as a JAR file which can then be included in an EAR file for deployment, or as a WAR file.

22.10.4.1 How to Create WebLogic SCA Projects

You begin developing a WebLogic SCA project by creating the WebLogic SCA Configuration file which acts as the control file for the application. As part of this process, JDeveloper configures either the JAR or WAR deployment descriptor for WebLogic SCA so that the necessary libraries are deployed to the server.

To create a WebLogic SCA application:

1. Create a Java application and project.
2. Choose File > New > New Gallery > Business Tier > Spring.
3. Choose either:

   • WebLogic SCA Configuration for JAR deployment to create a project that includes a JAR file that can be included in an EAR file for deployment.

   • WebLogic SCA Configuration for WAR deployment to create a project that includes a WAR file.

Example 22-2 What the WebLogic SCA Wizard Does

When you run the WebLogic SCA Configuration wizard, the following happens:

• An SCA definition file called spring-context.xml is created in META-INF/jsca and opened in the JDeveloper XML source editor. You can use the advanced XML editing framework to assist you as you edit it.

• If the project does not already contain a web.xml file one is created.

• Depending on the option you choose in the New Gallery:

  • A JAR deployment descriptor is added to the project, and a dependency on the weblogic-sca shared library is added at application level.

  • A WAR deployment descriptor is added to the project, and a dependency on the weblogic-sca shared library is added at web application level.

Example 22-3 Next Steps

Once you have created an SCA project, you can:

• Deploy the application to Oracle WebLogic Server.

• Test the application with the JDeveloper Integrated WebLogic Server.

22.10.4.2 How to Edit Oracle WebLogic SCA Definition Files

The SCA definition file created when you create a WebLogic SCA project is called spring-context.xml, and it is created in META-INF/jsca and opened in the XML source editor.

The following example shows the outline spring-context.xml file.

<?xml version="1.0" encoding="windows-1252" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:jee="http://www.springframework.org/schema/jee"
       xmlns:lang="http://www.springframework.org/schema/lang"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:sca="http://xmlns.oracle.com/weblogic/weblogic-sca"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd 
http://www.springframework.org/schema/util 
http://www.springframework.org/schema/util/spring-util-2.5.xsd 
http://www.springframework.org/schema/aop 
http://www.springframework.org/schema/aop/spring-aop-2.5.xsd 
http://www.springframework.org/schema/jee 
http://www.springframework.org/schema/jee/spring-jee-2.5.xsd 
http://www.springframework.org/schema/lang 
http://www.springframework.org/schema/lang/spring-lang-2.5.xsd 
http://www.springframework.org/schema/tx 
http://www.springframework.org/schema/tx/spring-tx-2.5.xsd 
http://www.springframework.org/schema/tool 
http://www.springframework.org/schema/tool/spring-tool-2.5.xsd 
http://xmlns.oracle.com/weblogic/weblogic-sca META-INF/weblogic-sca.xsd">
  <!--Spring Bean definitions go here-->
 
</beans> 
 

The comment shows where you enter the bean definitions.

Use the XML source editor features, Structure window features, the Components window, and the Properties window to navigate the hierarchy of the XML file and edit it.

Source Editor Features

The source editor has a number of features which help you to edit an XML file.

• XML Code Insight, the XML-specific implementation of completion insight. Type < and wait for a second, and JDeveloper will pop-up the possible entries appropriate for that location. If the tag you chose has mandatory attributes, JDeveloper will automatically add them.

• The XML source editor provides many features to help, for example, errors are underlined with a curly red line.

• You can choose options from the context menu such as Find Usages, which will display all the usages of the element in the Usages log window. You can also use Find Usages from the Structure window.

Structure Window Features

The Structure window allows you to quickly navigate the hierarchy of the XML file, and it also offers editing features.

• Right click on nodes in the Structure window to add more components.

• Error messages are displayed in the Structure window.

Components Window Features

You can select tags from the Components window and drag and drop them directly into the source editor or the Structure window to build spring-context.xml files.

Note:

You can only drop tags in places that are correct in terms of syntax.

By default, the Components window displays all the available tags. Click All Pages and choose just the type of tags you want to reduce the number of tags displayed. For example, to use WebLogic SCA Bindings, choose that option at the top of the Components window and the components listed are EJB Binding and Webservice Binding.

Properties Window Features

The Properties window allows you to edit the properties of tags.

• Changes in the Properties window are synchronized with the source editor view.

• Lists of values are shown when they are relevant for a specific property.

22.10.4.3 How to Deploy WebLogic SCA Applications to Integrated WebLogic Server

Once you have created a WebLogic SCA project you can test the application by quickly deploying it to the Integrated WebLogic Server.

To deploy to Integrated WebLogic Server, In the Applications window right-click spring-context.xml under the project node in the Applications window and choose Run, or Debug, or one of the Profiler options.

What Happens When You Run the Application in Integrated WebLogic Server

If Integrated WebLogic Server has not yet been started, the default domain is automatically created with default settings and the server is started.

The application is deployed to Integrated WebLogic Server and the Log Window displays messages that show the progress of the deployment.

In the Application Servers window, you can see the services deployed under the Web Services and EJB nodes under IntegratedWebLogicServer.

22.10.4.4 How to Deploy WebLogic SCA Applications to Oracle WebLogic Server

Once you have created a WebLogic SCA project you can deploy it to Oracle WebLogic Server.

The process is slightly different depending on whether you chose to create a JAR or a WAR file.

Note:

Before you deploy a WebLogic SCA application to Oracle WebLogic Server, you must install WebLogic SCA on the server. For more information, see the chapter about deploying WebLogic SCA Runtime to WebLogic Server in the Developing and Administering Spring Applications for Oracle WebLogic Server.

To deploy an Application Containing a WebLogic SCA WAR File to WebLogic Server, Deploy the application as usual.

To deploy an Application Containing a WebLogic SCA JAR File to WebLogic Server:

1. Set the location of the JAR file to be either lib or APP-INF/lib and deploy it into an EAR file.

   Note:

   The EAR file must contain at least one other Java EE artifact, for example a WAR file or EJB-JAR or the deployment will fail.

2. Deploy the application as usual.

Example 22-4 What Happens When You Deploy the Application to WebLogic Server

If necessary, an EAR file is created.

The application is deployed to the WebLogic Server connection and the Log Window displays messages that show the progress of the deployment.

In the Application Servers window, you can see the services deployed under the Web Services and EJB nodes under the connection node for the application server.

22.10.5 Using Spring

The Weblogic SCA Spring Extension provides integrated support for the open-source Spring framework. The extension adds a number of libraries to JDeveloper, and adds support for creating Spring framework projects

22.10.5.1 How to Create Spring Bean Applications

The Weblogic SCA Spring Extension adds libraries to JDeveloper containing the JAR files of the Spring framework. You begin developing a Spring framework application by creating the Spring Bean Configuration file, which acts as the control file for the application.

To create a Spring Bean Configuration file:

1. Create a Java application and project.
2. Choose File > New > New Gallery > Business Tier > Spring > Spring. Enter the file name and directory for the Spring Bean definition file and click OK.

22.10.5.2 What Happens When You Create a Spring Bean Configuration File

When you create a Spring Bean Configuration from the Spring category in the Business Tier of the New Gallery, the Spring 2.5 and Commons Logging 1.0.4 libraries are automatically added to the project. You can access the library definitions by choosing Project Properties from the context menu of the project in the Applications window, and then choosing Libraries and Classpath.

The Spring Bean Configuration file, beans.xml, is created in META-INF/jsca and opened in the XML source editor. You can use the advanced XML editing framework to assist you as you edit it.

22.11 Troubleshooting Deployment

There a number of common problems that you may come across when deploying applications. Learn what they are and see suggestions for solving them.

This topic is divided into issues that may arise when deploying to both Integrated WebLogic Server and Oracle WebLogic Server, and issues that are specific to one or other type of deployment.

22.11.1 Common Deployment Issues

This section contains information about issues that may arise when deploying to both Integrated WebLogic Server and Oracle WebLogic Server.

22.11.1.1 [Deployer: 149164] The domain edit lock is owned by another session in exclusive mode - hence this deployment operation cannot proceed

Oracle WebLogic Server instances use the domain edit lock to make sure that only one user can deploy applications and change configurations at one time, and this message is displayed when another deployment is going on at the same time (only one deployment at a time is allowed), or some change has been made in the WebLogic Server Administration Console that has not been activated. Rarely, this message may also appear when you are running an application on Integrated WebLogic Server.

To activate a change in the WebLogic Server Administration Console:

1. Log in to the Administration Console.
2. In the Change Center, at the upper left of the console, click View changes and restarts.
3. In the Changes and Restarts section, ensure that the Change List tab is selected, and activate any pending changes.
4. Select the Restart Checklist tab, and select the server to restart, and click Start.

To enable or disable the domain configuration locking feature, see the section about enabling and disabling the domain configuration lock in the Administration Console Online Help, which is available from the WebLogic Server online documentation in your JDeveloper installation, or from the Administration Console.

If the error has appeared when you are deploying to Integrated WebLogic Server, you can check the Administration Console to determine what the problem is.

22.11.2 How to Troubleshoot Deployment to Integrated Application Servers

This section contains information about issues that are specific to running on integrated application servers.

22.11.2.1 Stopping Integrated Application Server

If you need to stop integrated application server, for example, to clear out an orphaned WebLogic Server instance that was created and left running from an earlier JDeveloper session, and you are unable to do so from within JDeveloper, go to jdeveloper-user-home/DefaultDomain/bin, and run stopWebLogic.cmd (on Windows) or stopWebLogic.sh (on Linux). This gracefully shuts down the integrated application server so that it will not conflict with subsequent attempts to launch the integrated application server from JDeveloper.

You can force shutdown of an instance that is still actively under the JDeveloper control (that is, not orphaned) by pressing the Terminate button twice.

22.11.2.2 Running Out of Memory

If you run multiple applications on Integrated WebLogic Server, you may run out of memory and see the java.lang.OutOfMemoryError: PermGen space exception. To avoid this, increase the MEM_MAX_PERM_SIZE from the default of 128m to 256m, 512m, or higher. This is set in setStartupEnv.cmd (Windows) or setDomainEnv.sh (Linux), which is located at jdeveloper-user-home/DefaultDomain/bin.

You first need to stop Integrated WebLogic Server using one of the methods described above.

22.11.2.3 Reinstalling JDeveloper in a Different Location

If you reinstall JDeveloper into a new location, you may find that you have problems because the integrated application server uses some hard-coded references to JDeveloper. You must do one of:

• Set JDEV_USER_DIR to use a new system directory, described in Setting the User Home Directory.

• Delete the old system directory, so that JDeveloper regenerates a new system directory.

• In the Application Servers window, right-click on IntegratedWebLogicServer and select Delete Default Domain.

22.11.3 How to Troubleshoot Deployment to Oracle WebLogic Server

This section contains information about issues that are specific to deploying to Oracle WebLogic Server.

22.11.3.1 ORA-01005: null password given; logon denied

This is usually caused by a blank password in the <encrypted-password> entry of the application-name-jdbc.xml file or no <encrypted-password> entry at all.

22.11.3.2 ORA-01017: invalid username/password; logon denied

This is usually caused by the wrong password in the <encrypted-password> entry of the application-name-jdbc.xml file.

22.11.3.3 [Oracle JDBC Driver] Kerberos Authentication was requested, but is not supported by this Oracle Server

This will cause logon to be denied, and it is due to using the Oracle WebLogic Server database driver, weblogic.jdbcx.oracle.OracleDataSource. This driver is not certified by Oracle and should not be used.

22.11.3.4 Application Does Not Work After Creating a Global Data Source from the Oracle WebLogic Server Administration Console

Make sure there is a target domain selected for the data source. If you clicked Finish before the last panel of the wizard, then this was not done.

Also, make sure that the Java naming lookup call is correct if you are using a lookup in Java code. For example, if the connection name is connection1, the naming lookup should be java:comp/env/jdbc/connection1DS.

22.11.3.5 Redeploying an Application to a Server that is Down

You can only deploy an application once to a server that is down.

If you attempt to redeploy the same application to the same down server a second time, deployment fails with the following log message:

[03:29:47 PM] ---- Deployment started. ----
[03:29:47 PM] Target platform is (Weblogic 10.3).
[03:29:47 PM] Retrieving existing application information
[03:29:47 PM] Running dependency analysis...
[03:29:47 PM] Building...
[03:29:50 PM] Deploying 2 profiles...
[03:29:50 PM] Wrote Web Application Module to /path/oracle/jdeveloper/jdev/mywork/Application1/Project1/deploy/webapp1.war
[03:29:50 PM] Wrote Enterprise Application Module to /path/oracle/jdeveloper/jdev/mywork/Application1/application1.ear
[03:29:50 PM] Redeploying Application...
[03:29:50 PM] [Deployer:149034]An exception occurred for task [Deployer:149026]deploy application application1 on Server-1.: [DeploymentService:290049]Deploy failed for id '1,244,759,390,503' since no targets are reachable..
[03:29:50 PM] Weblogic Server Exception: java.lang.Exception: [DeploymentService:290049]Deploy failed for id '1,244,759,390,503' since no targets are reachable.
[03:29:50 PM] See server logs or server console for more details.
[03:29:50 PM] java.lang.Exception: [DeploymentService:290049]Deploy failed for id '1,244,759,390,503' since no targets are reachable.
[03:29:50 PM] #### Deployment incomplete. ####
[03:29:50 PM] Remote deployment failed

22.11.3.6 Attempting to Deploy to a Server that No Longer Exists

When you have successfully deployed an application to a Managed Server, the deployment wizard saves this deployment action in its history so that you can perform the same action later. However, if the Managed Server is removed from your Oracle WebLogic Server domain and you subsequently deploy using the deployment history action, deployment fails with the following log message:

[02:38:40 PM] ---- Deployment started. ----
[02:38:40 PM] Target platform is (Weblogic 10.3).
[02:38:40 PM] Retrieving existing application information
[02:38:40 PM] #### Deployment incomplete. ####
[02:38:40 PM] [J2EE Deployment SPI:260013]Target array passed to DeploymentManager was null or empty.

22.11.3.7 Deploying to a remove server fails with HTTP Error Code 502

If you are deploying to a server running on a machine that is not known to the network DNS server, and you have set a proxy for JDeveloper, deployment will fail with a 502 HTTP error code. This is because the proxy does not know where to forward the request. This will also happen if you are deploying to a server on the localhost that is referred to by its machine name, which typically happens with SOA development.

To avoid this happening either add the machine to the Exceptions list in the proxy settings in the Web Browser and Proxy page of the Preferences dialog, or choose not to use a HTTP Proxy Server for any connections.

22.11.3.8 No Credential Mapper Entry Found

If you see the following message, it usually means that an EAR using password indirection did not have the passwords injected via mbeans before deployment.

weblogic.common.ResourceException: No credential mapper entry found for password indirection user=scott for data source Connection1

This usually happens when trying to deploy an EAR manually from the console or from an ant script.

22.11.4 How to Troubleshoot Deployment to IBM WebSphere

This section contains information about issues that may arise when deploying to both Integrated WebLogic Server and Oracle WebLogic Server.

22.11.4.1 Deployment Fails When EAR Contains Spaces

WebSphere deployment on Windows does not work when the directory containing the EAR generated by JDeveloper contains spaces.

22.11.4.2 Deployment Fails When the Path to the WebSphere Server Contains Spaces

WebSphere deployment on Windows does not work when the path to wsadmin.bat contains spaces. See Connecting to WebSphere Server.

22.11.4.3 Application Displays Administrative Console User Name

When you deploy your application to IBM WebSphere application servers and use the same machine to log into the WebSphere administrative console, your application may display the name of the user logged into the administrative console, instead of the name of the user who logs into the application.