Skip Headers
Oracle® Fusion Middleware User's Guide for Oracle JDeveloper
11g Release 2 (11.1.2.2.0)

Part Number E17455-03
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

9 Deploying Applications

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

This chapter includes the following sections:

9.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 also use JDeveloper to run an application in the integrated 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.

If you are using Oracle® Fusion Middleware extensions, refer to the appropriate developer's guide for deployment information specific to the product. For example:

You can deploy applications in the following ways:

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, see the Oracle Fusion Middleware Java EE Developer's Guide for Oracle Application Development Framework.

Figure 9-1 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 Oracle Fusion Middleware Java EE Developer's Guide for Oracle Application Development Framework for deployment to Oracle WebLogic Server, or to the appropriate documentation for a third-party application server.

Figure 9-1 Deployment Overview Flow Diagram

Deployment overview flow diagram

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

You can use JDeveloper to:

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.

9.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 Application Navigator, or running an application by choosing Run from the JDeveloper main menu.

You debug the application using the features described in Chapter 7, "Building, Running and Debugging Applications."

9.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

  • Creating deployment profiles (if necessary)

  • Creating deployment descriptors (if necessary, and that are specific to the target application server)

  • Updating application.xml and web.xml to be compatible with the application server (if required)

  • Migrating application-level security policy data to a domain-level security policy store

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.

If necessary, 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. WAR and MAR files can be deployed only as part of an EAR file.

  • Use Enterprise Manager, scripts, or the application server's administration tools to deploy the EAR file created in JDeveloper. For more information, see the Oracle Fusion Middleware Administrator's Guide for Oracle Application Development Framework.

9.1.3 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.

9.1.4 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.

9.1.5 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.

9.1.6 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. For more information, see the section on Deployment Plans in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.

9.1.7 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. For more information about creating extensions to JDeveloper, see Oracle Fusion Middleware Developer's Guide for Oracle JDeveloper Extensions

9.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 workspace. JDeveloper then creates an in-memory deployment profile for deploying the application to the integrated application server. JDeveloper copies project and application workspace 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:

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 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 Server Navigator, right-click IntegratedWebLogicServer and choose Create Default Domain.

9.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. For more information, see the weblogic.xml descriptor elements information in Oracle Fusion Middleware Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server

9.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.

9.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 Application Navigator, 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.

9.2.3.1 How to Create a New Integrated Application Server Connection

To define an integrated server connection:

  1. In the Application Server Navigator, 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.

9.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 Application Navigator, 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 Application Navigator, 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 Navigator. 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.

9.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 Server Navigator.

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 Server Navigator by choosing View > Application Server Navigator.

  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. necessary, open the Application Server Navigator by choosing View > Application Server Navigator.

  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, click the Run Manager tab in the navigator, or select Run Manager from the View 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.

9.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 Chapter 7, "Building, Running and Debugging Applications."

To run an application in the integrated application server:

  1. In the Application Navigator, 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 Section 9.2.3.9, "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 Section 9.3.6.4, "Setting Up JDBC Data Sources on Oracle WebLogic Server"

9.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 Navigator, 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 Navigator.

After the server has started, click the Run Manager tab in the Navigator to display the integrated application server process. You can open the Run Manager by choosing View > Run Manager from the main menu.

To start an integrated application server:

  1. If necessary, open the Application Server Navigator by choosing View > Application Server Navigator.

  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 Server Navigator by choosing View > Application Server Navigator.

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

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

9.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:

  • n the Log Window, click the Terminate button and choose the profile or application you wish to cancel.

9.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 Run Manager. For more information, see Section 19.2, "Understanding the Run Manager."

You can open the Run Manager by choosing View > Run Manager 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 View > Run Manager 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 Server Navigator, 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.

9.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 Server Navigator by choosing View > Application Server Navigator.

  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.

9.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 Server Navigator.

  • By running an application.

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

  1. If necessary, open the Application Server Navigator by choosing View > Application Server Navigator.

  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.

9.3 Connecting and Deploying Java EE Applications to Application Servers

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

Figure 9-2 show 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 9-2 Preparing the Application for Deployment Flow Diagram

Preparing the application for deployment flow diagram

9.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.

Before you begin:

  • Ensure that the application server is installed and started.

  • If you are working behind a proxy server you need to configure JDeveloper to recognize the proxy server:

    1. Choose Tools > Preferences to open the Preferences dialog.

    2. Select Use HTTP Proxy Server and enter the hostname and port for the proxy server.

      Exceptions is populated with values from your machine. If you are deploying to a Oracle WebLogic Server configured to use SSL you should add *.company_name.com to the exception list.

To create a connection to an application server:

  1. Launch the Application Server Connection wizard.

    You can:

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

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

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

    • In the Resource Palette, choose New > New Connections > Application Server.

  2. In the Create AppServer Connection dialog Usage page, select Standalone Server.

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

  4. In the Connection Type dropdown list, choose:

    • WebLogic 10.3 to create a connection to Oracle WebLogic Server

    • JBoss 5.x to create a connection to JBoss

    • Tomcat 6.x to create a connection to Tomcat

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

  5. Click Next.

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

  7. Click Next.

  8. On the Configuration page, enter the information for your server:

    For WebLogic:

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

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

      If you don't 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) 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 don't 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.

    For JBoss:

    • Enter or browse to the location of the JBoss deploy directory, where your application files (.jar,.war,.ear) 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.

    For Tomcat:

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

    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) 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.

  9. Click Next.

  10. 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.

  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 Server Navigator.

Note:

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

  1. In the Application Server Navigator, 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 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.

9.3.2 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

9.3.2.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. 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.

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:

  • ADF Library JAR file: Used for deploying ADF components as an application JAR file, which can be reused in ADF applications, or it can be used to build other ADF libraries.

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

  • Business Components EJB Session Bean: Creates a profile for deploying ADF Business Components as an EJB session bean.

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

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

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

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

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

  • 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.

9.3.2.2 Creating Deployment Profiles

Deployment profiles can be created in various ways:

  • Use the Deployment page of the Application Properties dialog, which can be opened from:

    • The Application menu on the JDeveloper toolbar.

    • The context menu of an application.

    • The dropdown list on the Application Navigator toolbar.

  • Use the Deployment page of the Project Properties dialog, which can be opened from:

    • Select the project in the Application Navigator, and choose Project Properties from the Application menu on the JDeveloper toolbar.

    • The context menu of a project in the Application Navigator.

  • Use one of the wizards from the General - Deployment Profiles category of the New Gallery (choose New from the File menu to open the New Gallery). The new deployment profile will be added to your project properties. To create application level profiles, invoke the New Gallery at application level. To create project level profiles, invoke the New Gallery at project level.

  • If your project has a web.xml file, you can right-click it and choose Create WAR Deployment Profile.

  • If your project is EJB 3.0, you can right-click the bean class and choose Create EJB JAR Deployment Profile.

  • If your project has an application.xml, you can right-click it and choose Create EAR Deployment Profile.

To modify an existing deployment profile

  • right-click the project in the Application Navigator 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 Application Navigator and choose Application Properties then choose Deployment in the tree structure in the wizard, then select the deployment profile and choose Edit.

To activate a deployment profile:

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

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

    • Right-click the application in the Application Navigator 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 Application Navigator 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 Application Navigator, right-click the application and choose New.

    For a project level deployment profile, in the Application Navigator, 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.

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

  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.

9.3.2.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.

9.3.2.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 Dependency analysis file group type allows you to select contributors that are project files and their dependencies. Profiles migrated from previous versions will contain a Dependency Analysis file group.

  • 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.

9.3.3 How to Create and Edit Deployment Descriptors

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 workspace 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.

9.3.3.1 About 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 9-1 provides a description of these files and illustrates how they relate to one another.

Table 9-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.

For more information, see the chapter about client application deployment descriptor elements in Oracle Fusion Middleware Programming Stand-alone Clients for Oracle WebLogic Server.

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.

For more information, see Oracle Fusion Middleware Programming XML for Oracle WebLogic Server.

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.

For more information, see Oracle Fusion Middleware Programming Enterprise JavaBeans for Oracle WebLogic Server.

persistence-configuration.xml

For EJB 3.0 modules. The format of this file is defined in persistence-configuration.xsd.

For more information, see Oracle Fusion Middleware Programming Enterprise JavaBeans, Version 3.0 for Oracle WebLogic Server.

weblogic-cmp-rdbms-jar.xml

For EJB 2.1 modules. The format of this file is defined in weblogic-rdbms20-persistence.xsd.

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.

For more information, see tOracle Fusion Middleware Programming Resource Adapters for Oracle WebLogic Server.

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.

For more information, see Oracle Fusion Middleware Programming XML for Oracle WebLogic Server.

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.

For more information, see Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server.

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.

For more information, see Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.

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.

For more information, see Oracle Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server.

weblogic-jms.xml

The format of this file is defined by weblogic-jms.xsd.

Used to configure JMS drivers in the Oracle WebLogic Server.

For more information, see Oracle Fusion Middleware Programming JMS for Oracle WebLogic Server.

weblogic-webservices.xml

The format of this file is defined by weblogic-webservices.xsd.

For more information, see Oracle Fusion Middleware WebLogic Web Services Reference for Oracle WebLogic Server.


9.3.3.2 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 9-3 Dependencies Between Projects and Deployment Profiles

Dependencies between projects and 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)

9.3.3.2.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.

9.3.3.2.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.

9.3.3.3 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 Application Navigator, 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 can't 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 or workspace. 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 Application Navigator. This ensures that the application is created with the correct descriptors.

To inspect or change deployment descriptor properties:

  1. In the Application Navigator, 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.

9.3.3.4 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 Application Navigator 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.

9.3.4 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

9.3.5 How to Pass Options to Target Connections When Deploying

When deploying in JDeveloper, 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 Application Navigator, 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.

9.3.6 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.

9.3.6.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. For more information, see Section 9.3.6.4, "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.

9.3.6.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.

9.3.6.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 Sun's 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.

9.3.6.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 Section 9.3.1, "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.

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.

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

9.3.6.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.

9.3.7 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.

For more information, see the section about deployment plans in the chapter about configuring applications for production deployment in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.

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.

Example 9-1 Example of a Deployment Plan

<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.

9.3.7.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 Application Navigator, 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.

9.3.7.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. For more information, see the section about deployment plans in the chapter about configuring applications for production deployment in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.

  • Use the weblogic.PlanGenerator command-line tool to generate a deployment plan for an application that uses an EAR. For more information, see the reference chapter about weblogic.PlanGenerator command line tool in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.

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.

9.4 Deploying Java Applications

JDeveloper supports deployment of 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 Section 9.3, "Connecting and Deploying Java EE Applications to Application Servers."

9.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 Application Navigator.

  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 Application Navigator 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. Launch the executable JAR file from the command line

    java -jar myapp.jar
    

    where myapp represents your JAR file name.

9.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 Section 9.3.2, "How to Create and Edit Deployment Profiles."

To deploy an OSGi bundle in JDeveloper:

  1. Select and right-click the project in the Application Navigator.

  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.

9.5 Deploying Java EE Applications

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.

9.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 workspace. 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 Application Navigator 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 Application Navigator 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 and WAR 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 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.

9.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 Application Navigator 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 Application Navigator, then choose Deploy > deployment profile.

  3. In the Deployment Action page of the Deploy dialog, choose Deploy to RAR file.

9.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 Application Navigator 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.

9.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.

To deploy a MAR profile in an EAR:

  1. Create a MAR deployment profile.

  2. Choose Application > Deploy > deployment-profile. In the Deploy profile dialog, select Deploy to MAR. For more information at any time, press F1 or click Help from within the Deploy profile dialog.

    The Deploy to MAR option creates a metadata archive file, which is a convenient option that can be used to verify the MAR contents. The created metadata file should have the same MAR contents as the Export to Deployed Application option.

  3. To include a MAR profile in a new EAR, in the Application Properties dialog that is displayed when you finish creating the MAR profile, click New to create an application level EAR deployment profile.

    Alternatively, to add the MAR profile to an existing EAR profile, open the EAR profile.

  4. In the Edit EAR Deployment Profile Properties dialog, go to the Application Assembly page and ensure that the MAR profile is listed under Java EE Modules.

  5. Click OK.

  6. Deploy the Java EE EAR.

To export MAR contents to MDS repository and deploy it to a deployed application in a remote server:

  1. Create a MAR deployment profile.

  2. Choose Application > Deploy > deployment-profile. In the Deploy profile dialog, select Deploy to MAR. For more information at any time, press F1 or click Help from within the Deploy profile dialog.

    The Deploy to MAR option creates a metadata archive file, which is a convenient option that can be used to verify the MAR contents. The created metadata file should have the same MAR contents as the Export to Deployed Application option.

  3. To export the MAR contents to the MAR profile, choose Application > Deploy > deployment-profile. In the Deploy profile dialog, choose Export to a Deployed Application. For more information at any time, press F1 or click Help from within the Deploy profile dialog.

  4. Continue through the Deploy profile dialog. You can choose the server to deploy to, and then the deployed application in that server. You can also choose to use a sandbox instance before committing the deployment.

9.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 Navigator, right-click the project and choose Deploy > 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 Section 9.7, "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 Sun's Java SE browser plugin or bundle the Swing libraries for JVMs version 1.1 with your applet.

9.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.

To deploy create and deploy a shared library archive:

  1. Create a shared library deployment profile.

  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 Application Navigator 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 Next.

  6. On the Select Server Page, choose the application server connection and select Deploy as a shared Library. Click Finish.

9.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.

9.6 Post-Deployment Configuration

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

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:

9.7 Testing the Application and Verifying Deployment

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.

9.8 Deploying from the Command Line

Applications or modules can be deployed from JDeveloper without starting the JDeveloper IDE.

Before deploying from the command line, you need to run JDeveloper at least once to create a deployment profile for either the application by choosing the Deployment page of the Application Properties dialog or the Project Properties dialog, both of which are available from the Application menu.

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

9.8.1 How to Deploy from the Command Line

Applications or modules can be deployed from JDeveloper without actually starting the JDeveloper IDE itself. 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.

OJDeploy can run a deployment locally in-process, or submit to a background server, OJServer, using the -ojserver option.

9.8.1.1 Command Usage

Example 9-2 Using ojdeploy to Deploy from the Command Line

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

Table 9-2 Arguments That Can be Used With ojdeploy

Argument Description

profile

Name of the profile to deploy.

workspace

Full path to the JDeveloper application file (.jws)

project

Name of the JDeveloper project within the .jws where the deployment profile can be found. If omitted, the profile is assumed to be in the application.

buildfile

Full path to a build file for batch deploy.

buildfileschema

Print XML Schema for the build file.


Note:

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.

Table 9-3 Options Available to Use with ojdeploy

Option Description

-address

The listen address for OJServer. Defaults to localhost:2010. The default parts of the address may be omitted, for example, -address :2001 or -address fasup-pls01.

-basedir

Interpret path for application relative to a base directory. The built-in macro ${base.dir} captures the value of -basedir.

-clean

Deletes all files from the project output directory before compiling. Deployment will stop for that profile, if a file or directory could not be deleted.

-define

Allows for additional macros to be defined on the command-line. This can also be done in an XML build file using the <variable> element. Macros and options defined on the command line supplement, or override, those found in the <defaults> section of a build file if one is being used.

-failonwarning

Stop deployment on warnings.

-forcerewrite

Ensures 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 an application or project just needs to be packaged, and not compiled at this time.

-nodatasources

For Java EE applications, this prevents the weblogic-jdbc.xml file from being updated with connection information found in the JDeveloper IDE. This option is ignored for non-Java EE applications.

-nodependents

Dependent profiles are not deployed.

-ojserver

Runs the deployment job on an OJServer. All paths referenced by the other options should be accessible on the server.

-outputfile

Specifies an alternate location for any JAR files created from the profile. The default is within a /deploy directory inside the project or application. If this parameter does not specify a file extension, the extension is determined from the original file name in the deployment profile.

-statuslogfile

Full path to an output file for status summary. No macros allowed. The -statuslogfile option 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.

-stdout, -stderr

Lets these streams be redirected to a file for each profile and project. You can use macros in the name or path of the files.

-timeout

Specify the number of seconds after which deployment of a single profile should be aborted.

-updatewebxmlejbrefs

Update EJB references in web.xml.


Table 9-4 Macros Available to Use with ojdeploy

Macro Description

workspace.name

Name of the application (without the .jws extension).

workspace.dir

Directory of the application .jws file.

project.name

Name of the project (without the .jpr extension).

project.dir

Directory of the project.jpr file.

profile.name

Name of the profile being deployed.

deploy.dir

Default deploy directory for the profile.

base.dir

Override the current OJDeploy directory using this parameter. You can also override the current OJDeploy directory using the basedir attribute in the build script.


Note:

The project.name and project.dir macros 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 an application-level profile:

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

Deploy all profiles from all projects of an application:

  • 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

9.8.1.2 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 will add 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:

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

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

9.8.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 a workspace, 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>

9.8.2.1 How to Use Wildcard Samples

Project and profile names can be specified as "*" or "name*" or "name1,name2,name3,..." or any combination of these. Workspace names need to be enumerated, so "*" is not allowed in workspace names, but workspace names can be specified as "workspace1" or "workspace1,workspace2,workspace3".

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>

9.8.2.2 How to Use Built-in Macros

The following built-in macros can be used in build files:

Table 9-5 Macros Available to Use With Build Files

Macro name Description

${workspace.name}

Name of application, excluding the vT file extension.

${workspace.dir}

Directory containing the application (.jws) file.

${project.name}

Name of project, excluding the .jpr file extension.

${project.dir}

Directory containing the project (.jpr) file.

${profile.name}

Defined name of the profile.

${deploy.dir}

Default deploy directory, usually ${project.dir}/deploy for project-level profiles or ${workspace.dir}/deploy for workspace-level profiles.

${base.dir}

Value of the -basedir parameter, or the current directory.


9.8.2.3 How to Create a Log File for Batch Deployment

You can use the parameter -statuslogfile c to provide the absolute path to a log file. The path should not contain 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.

Example 9-3 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>

9.8.3 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 workspace. A command-line tool, OJDeploy, is available to allow deployment of 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 need to be created manually. The resulting deployed archive depends on version of JDeveloper used, and which extensions are enabled when command line deployment is invoked

9.8.3.1 How to Generate an Ant Build Script

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

Example 9-4 Structure of the Ant Build Script

<project name="Project1" default="all" basedir=".">
 <property file="build1.properties"/>
 <target name="init">
 <tstamp/>
 <mkdir dir="${output.dir}"/>
 </target>
 <target name="all" description="Build the project" depends="compile,copy,deploy"/>
 <target name="clean" description="Clean the project">
   . . .
 </target> <target name="compile" description="Compile Java source files" depends="init">
   . . .
 </target>
 <target name="copy" description="Copy files to output directory" depends="init">
   . . .
 </target>
 <!--- This is the additional part generated for deployment ---->
 
 <target name="deploy" description="Deploy JDeveloper profiles"
   depends="init,compile">
 <taskdef name="ojdeploy"
   classname="oracle.jdeveloper.deploy.ant.OJDeployAntTask"
   uri="oraclelib:OJDeployAntTask"
   classpath="${oracle.jdeveloper.ant.library}"/>
 <ora:ojdeploy xmlns:ora="oraclelib:OJDeployAntTask"
   executable="${oracle.jdeveloper.ojdeploy.path}"
   ora:buildscript="${oracle.jdeveloper.deploy.dir}ojdeploy-build.xml"
   ora:statuslog="${oracle.jdeveloper.deploy.dir}ojdeploy-statuslog.xml">
 <ora:deploy>
 <ora:parameter name="workspace"
   value="${oracle.jdeveloper.workspace.path}"/>
 <ora:parameter name="project"
   value="${oracle.jdeveloper.project.name}"/>
 <ora:parameter name="profile"
   value="${oracle.jdeveloper.deploy.profile.name}"/>
 <ora:parameter name="nocompile" value="true"/>
 <ora:parameter name="outputfile"
   value="${oracle.jdeveloper.deploy.outputfile}"/>
 </ora:deploy>
 </ora:ojdeploy>
 </target>
 <!-------------- end of deployment ---->
 </project>

9.8.3.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:.

Example 9-5 Example of the build.xml File

#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

9.8.3.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 Application Navigator and selecting the "all" or the "deploy" targets.

Example 9-6 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

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.

9.9 Deploying Using Java Web Start

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 allows you to deploy Java applications so that they can be launched from an internet browser. 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.

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.

9.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.

9.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:

9.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.

9.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.

9.9.3 How to Create an ADF Swing Web Archive for Java Web Start

You can use the JDeveloper 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.

How to create the ADF Swing web application archive for Java Web Start:

  1. Before creating your archive files to ensure that you archive the latest source files, create both the following:

    • The Business Component project.

    • The ADF Swing project.

  2. Run the ADF Swing Java Web Start dialog. In the Application Navigator, select the application or project in which you are working.

    Choose File > New to open the New Gallery.

    In the Categories tree, expand Client Tier and select ADF Swing. In the Items list, select Java Web Start (JNLP) Files for ADF Swing, and click OK.

    The dialog generates JNLP files for use with Java Web Start, an ANT build file ctbuild.xml, and a deployment profile in the project properties.

  3. If for security reasons the password used for the Java keystore defined on the machine differs from the password used to protect the key and sign the code, then you must modify the ctbuild.xml ANT build file to reference the specified password:

    • Open the ctbuild.xml file and add the property for the key password below the other signing properties:

      <!--properties related to signing-->
      <property name="alias" value="ADFADF SwingTrust"/>
      <property name="storepass" value="welcome"/>
      <property name="keypass" value="myPassword"/>
      
    • Change the sign target from the following:

      <target name="sign" depends="jar"> 
         <signjar jar="${mt.jar.name}" alias="${alias}" storepass="${storepass}"/> 
         <signjar jar="${ct.jar.name}" alias="${alias}" storepass="${storepass}"/>
      </target>
      

      to:

      <target name="sign" depends="jar"> 
         <signjar jar="${mt.jar.name}" alias="${alias}" keypass="${keypass}" storepass="${storepass}"/> 
         <signjar jar="${ct.jar.name}" alias="${alias}" keypass="${keypass}" storepass="${storepass}"/> 
      </target>
      
  4. To create the client side archive files, right-click ctbuild.xml in the ADF Swing project and choose:

    Build Target > sign to require authentication of the archive, this will sign the contained JAR files and is a required step.

    The build file should generate two signed archive files in your project's public_html directory: client.jar and mymt.zip. These archives are referenced by the generated deployment profile in the project's properties.

  5. (Optional) If you want to edit the web.xml deployment descriptor, right-click the web.xml file in the Application Navigator and choose Open.

  6. (Optional) To reopen a project deployment profile later to make changes, right-click the project in the Application Navigator 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 and EAR files to the target application server, make sure to create an application server connection.

9.9.4 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 Application Navigator, 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 Application Navigator 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 Application Navigator and choose Open.

  10. (Optional) To reopen a project deployment profile later to make changes, right-click the project in the Application Navigator 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.

9.9.5 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 Navigator, 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:

Example 9-7 JNLP File

<%@ 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>

9.9.6 How to Deploy an ADF Swing Web Application Archive for Java Web Start

You can deploy the ADF Swing Web Archive to a server. Install the Java Web Start software on your machine. For more information on Java Web Start, see http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html.

To deploy the ADF Swing web application archive for Java Web Start:

  1. If not already done, create a signed ADF Swing Web Archive for Java Web Start.

  2. If not already done, create an application server connection to the target application server.

  3. Right-click the ADF Swing project and choose Deploy to automatically generate the WAR file and deploy the application components. You must choose a connection to the desired web server.

  4. (Optional) If you want to edit the web.xml deployment descriptor, right-click the web.xml file in the Application Navigator and choose Open.

  5. (Optional) To reopen a project deployment profile later to make changes, right-click the project in the Application Navigator and choose Project Properties, then select the name of the profile in the Deployment section of the Project Properties dialog and click Edit.

9.9.7 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 Application Navigator. 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 Application Navigator and choose Open.

  7. (Optional) To reopen a project deployment profile later to make changes, right-click the project in the Application Navigator 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.

9.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:

9.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. For more information, see http://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 Section 9.10.4.3, "How to Deploy WebLogic SCA Applications to Integrated WebLogic Server."

For more information about Oracle WebLogic SCA, see Oracle Fusion Middleware Developing WebLogic SCA Applications for Oracle WebLogic Server.

9.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 Oracle Fusion Middleware Spring Support in Oracle WebLogic Server.

9.10.3 Installing the Weblogic SCA Spring Extension

In order 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.

9.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.

9.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.

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.

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.

9.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 outline spring-context.xml file is

Example 9-8 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 Component Palette, and the Property Inspector 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.

Component Palette Features

You can select tags from the Component Palette 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 Component Palette 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 component palette and the components listed are EJB Binding and Webservice Binding.

Property Inspector Features

The Property Inspector allows you to edit the properties of tags.

  • Changes in the property inspector are synchronized with the source editor view.

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

9.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 Application Navigator right-click spring-context.xml under the project node in the Application Navigator, 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 Server Navigator, you can see the services deployed under the Web Services and EJB nodes under IntegratedWebLogicServer.

9.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 Oracle Fusion Middleware Spring Support in 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.

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 Server Navigator, you can see the services deployed under the Web Services and EJB nodes under the connection node for the application server.

9.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

9.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.

9.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 Application Navigator, 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.

9.11 Troubleshooting Deployment

There a number of common problems that you may come across when deploying applications. This topic describes them and their solutions. It 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

9.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.

9.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.

9.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.

9.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 (i.e., not orphaned) by pressing the Terminate button twice.

9.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 setDomainEnv.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.

9.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. This is described in "Setting the User Home Directory" in the Oracle Fusion Middleware Installation Guide for Oracle JDeveloper.

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

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

9.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.

9.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.

9.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.

9.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.

9.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.

9.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

9.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.

9.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.

9.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.

9.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.

9.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.

9.11.4.2 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.