Skip to end of metadata
Go to start of metadata

The purpose of this guide is to document the application changes that are needed to successfully run and deploy WebLogic applications on AS 7. The following is a rough outline of topics to addressed.

Feel free to add content in any way you prefer. You do not need to follow the template below. This is a work in progress.

Introduction

About this Guide

The purpose of this document is to guide you through the planning process and migration of fairly simple and standard Oracle WebLogic applications to JBoss AS 7.  Oracle WebLogic applications that adhere to the Java EE 6 specification should require minimal changes to run on JBoss AS 7.

This document will not cover migration of advanced features such as portal, rules engines, workflow systems, or ESB frameworks. Red Hat Consulting and Red Hat partners offer a wide variety of workshops, training, and service offerings designed to help customers migrate more complex applications.

Introduction to the JBoss AS 7 Server

JBoss AS 7 is a fast, secure, powerful middleware platform built upon open standards, and compliant with the Java Enterprise Edition 6 specification. It integrates JBoss Application Server 7 with high-availability clustering, powerful messaging, distributed caching, and other technologies to create a stable and scalable platform. JBoss AS 7 is a certified implementation of the Java Enterprise Edition 6 Full Profile and Web Profile specifications.

The new modular structure allows for services to be enabled only when required, significantly increasing start up speed. The Management Console and Management Command Line Interface remove the need to edit XML configuration files by hand, adding the ability to script and automate tasks. In addition, it includes APIs and development frameworks that can be used to develop secure, powerful, and scalable Java EE applications quickly.

For more information about JBoss AS 7, see Getting Started with JBoss Application Server 7 .

Java Enterprise Edition 6 Overview

Overview of Java EE 6 Profiles

Java Enterprise Edition 6 (EE 6) includes support for multiple profiles, or subsets of APIs. The only two profiles that the EE 6 specification defines are the Full Profile and the Web Profile.
EE 6 Full Profile includes all APIs and specifications included in the EE 6 specification. EE 6 Web Profile includes a subset of APIs which are useful to web developers.

JBoss AS 7 is a certified implementation of the Java Enterprise Edition 6 Full Profile and Web Profile specifications.

Java Enterprise Edition 6 Web Profile

The Web Profile is one of two profiles defined by the Java Enterprise Edition 6 specification. It is designed for web application development.

Java EE 6 Web Profile Requirements
  • Java Platform, Enterprise Edition 6
  • Java Web Technologies
    • Servlet 3.0 (JSR 315)
    • JSP 2.2 and Expression Language (EL) 1.2
    • JavaServer Faces (JSF) 2.0 (JSR 314)
    • Java Standard Tag Library (JSTL) for JSP 1.2
    • Debugging Support for Other Languages 1.0 (JSR 45)
  • Enterprise Application Technologies
    • Contexts and Dependency Injection (CDI) (JSR 299)
    • Dependency Injection for Java (JSR 330)
    • Enterprise JavaBeans 3.1 Lite (JSR 318)
    • Java Persistence API 2.0 (JSR 317)
    • Common Annotations for the Java Platform 1.1 (JSR 250)
    • Java Transaction API (JTA) 1.1 (JSR 907)
    • Bean Validation (JSR 303)

Java Enterprise Edition 6 Full Profile

The Java Enterprise Edition 6 (EE 6) specification defines a concept of profiles, and defines two of them as part of the specification. Besides the items supported in the Java Enterprise Edition 6 Web Profile, the Full Profile supports the following APIs. JBoss AS 7 supports the Full Profile.

Items Included in the EE 6 Full Profile
  • EJB 3.1 (not Lite) (JSR 318)
  • Java EE Connector Architecture 1.6 (JSR 322)
  • Java Message Service (JMS) API 1.1 (JSR 914)
  • JavaMail 1.4 (JSR 919)
  • Web Service Technologies
    • Jax-RS RESTful Web Services 1.1 (JSR 311)
    • Implementing Enterprise Web Services 1.3 (JSR 109)
    • JAX-WS Java API for XML-Based Web Services 2.2 (JSR 224)
    • Java Architecture for XML Binding (JAXB) 2.2 (JSR 222)
    • Web Services Metadata for the Java Platform (JSR 181)
    • Java APIs for XML-based RPC 1.1 (JSR 101)
    • Java APIs for XML Messaging 1.3 (JSR 67)
    • Java API for XML Registries (JAXR) 1.0 (JSR 93)
  • Management and Security Technologies
    • Java Authentication Service Provider Interface for Containers 1.0 (JSR 196)
    • Java Authentication Contract for Containers 1.3 (JSR 115)
    • Java EE Application Deployment 1.2 (JSR 88)
    • J2EE Management 1.1 (JSR 77)

JBoss AS 7 Architectural Overview

The following sections highlight some basic information about JBoss Enterprise Application Platform 6. For complete information on how to download, install, configure, and develop applications, refer to the Installation Guide, Administration and Configuration Guide, and Development Guide located on the Customer Portal .

Review What's New and Different in JBoss AS 7

The following is a list of notable differences in JBoss AS 7 from the previous release.

Module based class loading

In previous releases of JBoss AS, the class loading architecture was hierarchical. In JBoss AS 7, class loading is based on JBoss Modules. This offers true application isolation, hides server implementation classes, and only loads the classes your application needs. Class loading is concurrent for better performance. Applications written for JBoss Enterprise Application Platform 5 must be modified to specify module dependencies and in some cases, repackage archives. For more information, refer to Class Loading and Modules in the Development Guide for JBoss Enterprise Application Platform 6 on the Customer Portal .

Domain Management

In JBoss AS 7, the server can be run as a standalone server or in a managed domain. In a managed domain, you can configure entire groups of servers at once, keeping configurations synchronized across your entire network of servers. While this should not impact applications built for previous releases, this can simplify management of deployments to multiple servers. For more information, refer to About Managed Domains in the Administration and Configuration Guide for JBoss Enterprise Application Platform 6 on the Customer Portal .

Domain mode is not supported in the following JBoss Enterprise products:
  • JBoss Portal Platform 6
Deployment Configuration
Standalone Servers and Managed Domains

JBoss AS 7 used profile based deployment configuration. These profiles were located in the JBOSS_HOME/server/ directory. Applications often contained multiple configuration files for security, database, resource adapter, and other configurations. In JBoss Enterprise Application Platform 6, deployment configuration is done using one file. This file is used to configure all the services and subsystems used for the deployment. A standalone server is configured using the JBOSS_HOME/standalone/configuration/standalone.xml file. For servers running in a managed domain, the server is configured using the JBOSS_HOME/domain/configuration/domain.xml file. The information contained in the multiple JBoss Enterprise Application Platform 5 configuration files must be migrated to the new single configuration file.

Ordering of deployments

JBoss AS 7 uses fast, concurrent initialization for deployment resulting in improved performance and efficiency. In most cases, the application server is able to automatically determine dependencies in advance and choose the most efficient deployment strategy. However, JBoss Enterprise Application Platform 5 applications that consist of multiple modules deployed as EARs and use legacy JNDI lookups instead of CDI injection or resource-ref entries may require configuration changes.

Directory Structure and Scripts

As previously mentioned, JBoss AS 7 no longer uses profile based deployment configuration, so there is no JBOSS_HOME/server/ directory. Configuration files for standalone servers are now located in the JBOSS_HOME/standalone/configuration/ directory and deployments are located in the JBOSS_HOME/standalone/deployments/ directory. For servers running in a managed domain, configuration files can be found in the JBOSS_HOME/domain/configuration/ directory and deployments can be found in the JBOSS_HOME/domain/deployments/ directory.
In JBoss Enterprise Application Platform 5, the Linux script JBOSS_HOME/bin/run.sh or Windows script JBOSS_HOME/bin/run.bat was used to start the server. In JBoss Enterprise Application Platform 6, the server start script is dependent on how you run your server. The Linux script JBOSS_HOME/bin/standalone.sh or Windows script JBOSS_HOME/bin/standalone.bat is used to start a standalone server. The Linux script JBOSS_HOME/bin/domain.sh or Windows script JBOSS_HOME/bin/domain.bat is used to start a managed domain.

JNDI Lookups

JBoss AS 7 now uses standardized portable JNDI namespaces. Applications that use other types of JNDI lookups must be changed to follow the new standardized JNDI namespace convention. For more information about JNDI naming syntax, see the section below on “Portable JNDI Naming Syntax”.

Modules and Modular Class Loading

Class loading in AS 7 is based on the JBoss Modules project.

Modules

A Module is a logical grouping of classes used for class loading and dependency management. JBoss AS 7 identifies two different types of modules, sometimes called static and dynamic modules. However the only difference between the two is how they are packaged. All modules provide the same features.

Static Modules

Static Modules are predefined in the JBOSS_HOME/modules/ directory of the application server. Each sub-directory represents one module and contains one or more JAR files and a configuration file (module.xml). The name of the module is defined in the module.xml file. All the application server provided APIs are provided as static modules, including the Java EE APIs as well as other APIs such as JBoss Logging. The following is an example module.xml file.

The module name, com.mysql, should match the directory structure for the module.

Creating custom static modules can be useful if many applications are deployed on the same server that use the same third party libraries. Instead of bundling those libraries with each application, a module containing these libraries can be created and installed by the JBoss administrator. The applications can then declare an explicit dependency on the custom static modules.

h6, Dynamic Modules
Dynamic Modules are created and loaded by the application server for each JAR or WAR deployment, or subdeployment in an EAR. The name of a dynamic module is derived from the name of the deployed archive. Because deployments are loaded as modules, they can configure dependencies and be used as dependencies by other deployments.

Modules are only loaded when required. This usually only occurs when an application is deployed that has explicit or implicit dependencies.

For more information on modular class loading, see Class Loading in AS7 .

Modules and Class Loading in Enterprise Archives

Enterprise Archives (EAR) are not loaded as a single module like JAR or WAR deployments. They are loaded as multiple unique modules.

The following rules determine what modules exist in an EAR.

  • Each WAR and EJB JAR subdeployment is a module.
  • The contents of the lib/ directory in the root of the EAR archive is a module. This is called the parent module.

These modules have the same behavior as any other module with the following additional implicit dependencies:

  • WAR subdeployments have implicit dependencies on the parent module and any EJB JAR subdeployments.
  • EJB JAR subdeployments have implicit dependencies on the parent module and any other EJB JAR subdeployments.
    No subdeployment ever gains an implicit dependency on a WAR subdeployment. Any subdeployment can be configured with explicit dependencies on another subdeployment as would be done for any other module.

The implicit dependencies described above occur because JBoss AS 7 has subdeployment class loader isolation disabled by default.

Subdeployment class loader isolation can be enabled if strict compatibility is required. This can be enabled for a single EAR deployment or for all EAR deployments. The Java EE 6 specification recommends that portable applications should not rely on subdeployments being able to access each other unless dependencies are explicitly declared as Class-Path entries in the MANIFEST.MF file of each subdeployment.

Directory Structure of JBoss AS 7

JBoss AS 7 includes a simplified directory structure, compared to previous versions. The following table contains a listing of the directories and a description of what each directory contains. It also includes directory structures of the standalone/ and domain/ folders.

Top-level Directories
Name Purpose
appclient/ Contains configuration details for the application client container.
bin/ Contains start-up scripts for JBoss EAP 6 on Red Hat Enterprise Linux and Microsoft Windows.
bundles/ Contains OSGi bundles which pertain to JBoss EAP 6 internal functionality.
docs/ License files, schemas, and examples.
domain/ Configuration files, deployment content, and writable areas used when JBoss EAP 6 runs as a managed domain.
modules/ Modules which are dynamically loaded by JBoss EAP 6 when services request them.
standalone/ Configuration files, deployment content, and writable areas used when JBoss EAP 6 runs as a standalone server.
welcome-content/ Contains content used by the Welcome web application which is available on port 8080 of a default installation.
jboss-modules.jar The bootstrapping mechanism which loads modules.
Directories within the domain/ directory
Name Purpose
configuration/ Configuration files for the managed domain. These files are modified by the Management Console and Management CLI, and are not meant to be edited directly.
data/ Information about deployed services. Services are deployed using the Management Console and Management CLI, rather than by a deployment scanner. Therefore, do not place files in this directory manually.
log/ Contains the run-time log files for the host and process controllers which run on the local instance.

servers/ Contains the equivalent data/, log/, and tmp/ directories for each server instance in a domain, which contain similar data to the same directories within the top-level domain/ directory. |

tmp/ Contains temporary data such as files pertaining to the shared-key mechanism used by the Management CLI to authenticate local users to the managed domain.
Directories within the standalone/ directory
Name Purpose
configuration/ Configuration files for the standalone server. These files are modified by the Management Console and Management CLI, and are not meant to be edited directly.
deployments/ Information about deployed services. The standalone server does include a deployment scanner, so you can place archives in this directory to be deployed. However, the recommended approach is to manage deployments using the Management Console or Management CLI.
lib/ External libraries which pertain to a standalone server mode. Empty by default.
tmp/ Contains temporary data such as files pertaining to the shared-key mechanism used by the Management CLI to authenticate local users to the server.

Deployment

TODO: section is not complete.

Administration Tools

Management Console

The Management Console is a web-based administration tool used to to start and stop servers, deploy and undeploy applications, tune system settings, and make persistent modifications to the server configuration. The Management Console also has the ability to perform administrative tasks, with live notifications when any changes require the server instance to be restarted or reloaded. In a Managed Domain, server instances and server groups in the same domain can be centrally managed from the Management Console of the domain controller.

JBoss CLI

The Management Command Line Interface (CLI) is a command line administration tool that can perform operations in batch modes, allowing multiple tasks to be run as a group.

JON

TODO: section is not complete.

Prepare for Migration

Before you attempt to migrate your WebLogic application to JBoss AS 7, it helps to have an understanding of the process.

Become Familiar with Java EE 6

JBoss AS 7 is a fast, lightweight, powerful implementation of the Java Enterprise Edition 6 specification, so understanding Java EE 6 is a great place to start. You can find Java Enterprise Edition 6 documentation here: http://www.oracle.com/technetwork/java/javaee/tech/index.html and a Java EE 6 tutorial here: http://docs.oracle.com/javaee/6/tutorial/doc/.

Become Familiar with JBoss AS 7

See the Admin Guide and Developer Guide for details on how to configure and develop applications with JBoss AS 7.

Identify the current hardware and operating systems

This includes the operating systems and versions, number of processors, memory capacity, disk usage and capacity.

Examine the existing WebLogic application server and platform

Examine the existing application server and platform, including the operating systems, JVMs, databases, and web servers, and determine the equivalent capabilities in JBoss AS 7. The supported JBoss configurations can be found on the Customer Portal at https://access.redhat.com/support/configurations/jboss/.

Examine and understand the existing WebLogic application

Thoroughly examine the existing WebLogic application. Be totally familiar with its architecture, functions, features and components. In particular, note the proprietary APIs and features and determine the JBoss or Java EE 6 equivalents.

Review monitoring and administration procedures and tools

Perform a review of all monitoring and administration procedures and tools in place to identify any that may need modification or replacement to work with the JBoss AS 7.

Review resources available for the migration process

Resources include people, software, and hardware. Assess the skills of the development team that will be doing the work and plan for training or additional consulting help. Also be aware that additional hardware and other resources will be required during the migration process until the effort is completed.

Prepare a migration plan

Develop a migration plan including a detailed roadmap and resources that will be needed.

Execute the plan

Implement the strategic migration plan and employ implementation support strategies.

Server Configuration and Deployment Descriptor Files

WebLogic and JBoss Server Configuration File

WebLogic Server Configuration and Deployment Descriptor Files

Configuration of the WebLogic Server is centralized in the WEBLOGIC_HOME/domains/DOMAIN_NAME/config/config.xml file. It contains the configuration parameter settings for each server instance, cluster, resource, and service in the domain. In most cases you use the Administration Console or one of the other WebLogic tools to modify the domain's configuration and the changes are then reflected in the configuration files.

JBoss AS 7 Configuration File

In JBoss AS 7, the server can be run as a standalone server or in a managed domain. A standalone server is configured using the JBOSS_HOME/standalone/configuration/standalone.xml file. For servers running in a managed domain, the server is configured using the JBOSS_HOME/domain/configuration/domain.xml and JBOSS_HOME/domain/configuration/host.xml files. In most cases you will not edit these files directly. You can use the Management Console or Management Command Line Interface (CLI) to configure the server and the changes will be reflected in the server configuration file. You can find more information about the Management CLI here: CLI Recipes.

Migrate the Server Configuration

Unfortunately, server configuration is a complex process and there is not an easy mapping from one application server to another. The best approach is to open the WebLogic configuration file and examine each section. Use the Admin Guide to find information about how to perform the same configuration in JBoss.

Map Configuration Files and Descriptors to the JBoss Equivalent

WebLogic configuration files are fairly complex and it can be difficult to map them to JBoss  equivalents, but the following table can be used as a guideline:

WebLogic File AS 7 Equivalent Description of the File
ejb-jar.xml, weblogic-ejb-jar.xml, or weblogic-cmp-rdbms-jar.xml jboss-ejb3.xml, standalone.xml, or domain.xml Deployment descriptor file describes the EJB elements that are unique to WebLogic Server.
weblogic.xml standalone.xml or domain.xml Deployment descriptor for web applications to support value-added features that are not included in the standard specifications.
*-jdbc.xml standalone.xml or domain.xml JDBC datasource descriptor file. In JBoss, this information is specified in the datasources subsystem of the JBoss configuration file.

Replace the weblogic-ejb-jar.xml Deployment Descriptor

The WebLogic weblogic-ejb-jar.xml deployment descriptor file describes elements that are specific to the WebLogic Server. The equivalent file in JBoss AS 7 is the jboss-ejb3.xml file. Many of these elements map to the jboss-ejb3.xml file in The equivalent file in JBoss Enterprise Application Platform 6. Some elements, however, map to other descriptor files.

Map weblogic-ejb-jar.xml Elements to the jboss-ejb3.xml Descriptor

The following table maps the WebLogic XPath elements to the corresponding JBoss XPath elements for various types of beans.

WebLogic weblogic-ejb-jar.xml XPath Element JBoss jboss-ejb3.xml XPath Element
WEBLOGIC_PREFIX/ejb-name JBOSS_PREFIX/ejb-name
WEBLOGIC_PREFIX/resource-description/res-ref-name JBOSS_PREFIX/resource-ref/res-ref-name
WEBLOGIC_PREFIX/resource-env-description/res-env-ref-name JBOSS_PREFIX/resource-env-ref/resource-env-ref-name
WEBLOGIC_PREFIX/ejb-reference-description/ejb-ref-name JBOSS_PREFIX/ejb-ref/ejb-ref-name
WEBLOGIC_PREFIX/service-reference-description/service-ref-name JBOSS_PREFIX/service-ref/service-ref-name
WEBLOGIC_PREFIX/service-reference-description/wsdl-file JBOSS_PREFIX/service-ref/wsdl-file
For readability, the variables WEBLOGIC_PREFIX and JBOSS_PREFIX were used in place of paths in the table.
  • For WebLogic descriptor elements, replace the variable WEBLOGIC_PREFIX with the following path prefix: /weblogic-ejb-jar/weblogic-enterprise-bean for all bean types.
  • For JBoss descriptor elements, replace the variable JBOSS_PREFIX with the following file path prefix depending on the bean type:
    • Entity Bean: /ejb-jar/enterprise-beans/entity
    • Session Bean: /ejb-jar/enterprise-beans/session
    • Message-Driven Bean: /ejb-jar/enterprise-beans/message-driven

Map Additional weblogic-ejb-jar.xml Elements to the JBoss Enterprise Application Platform Equivalent

The following list describes how to map addtional elements to the JBoss Enterprise Application Platform Equivalent.

  • delay-updates-until-end-of-tx
    This element in the webLogic-ejb-jar.xml file, which defaults to True, is used for performance reasons to delay updates to the persistent store of all beans until the end of the transaction. When set to False, updates are sent to the database after each method invocation, but are not committed until the end of the transaction. This allows other processes to access the persisted data while the transaction is waiting to be completed. In JBoss Enterprise Application Platform 6, you can achieve the same behavior by specifying the <sync-on-commit-only> in the jbosscmp-jdbc.xml file. For example:

    This feature is available in JBoss Enterprise Application Platform 6.1. For JBoss Enterprise Application Platform 6.0.x, it is available as a patch.

Migrate weblogic.xml Descriptor File Configurations

he weblogic.xml deployment descriptor file is used to support value-added features that are not included in the standard specifications for web applications. While there is no direct mapping of these descriptor elements, many of these features may be configured in the application deployment or JBoss server configuration files. The following section provides examples of how to map a few common configurations. For more information on how to configure the JBoss server, refer to the Administration and Configuration Guide for JBoss Enterprise Application Platform 6 on https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

The table that follows uses this weblogic.xml file as the example.

The following table maps the some common weblogic.xml configurations to JBoss

weblogic.xml JBoss Equivalent
Specify the context root:
Add the following to the WEB-INF/jboss-web.xml file
Map roles:
Use the RoleMappingLoginModule in the server configuration file

Then add the following to the WEB-INF/jboss-web.xml:

Specify Session Timeout:
Add the following to the WEB-INF/jboss-web.xml:
Specify class loading precedence:
Since the WAR has its own scoped class loader, the classes packaged in the WEB-INF/lib and WEB-INF/classes directories will always be loaded from inside the web application. There is no known alternative/relative configuration in JBoss.
Configure JSPs:
Configure JSPs in the web subsystem of the server configuration file.

Migrate weblogic-application.xml Descriptor File Configurations

The weblogic-application.xml deployment descriptor file is used to describe WebLogic EAR archives. While there is no direct mapping of these descriptor elements, many of these features may be configured in standard Java EE files. The following example shows how to map a few common elements. For more information on how to configure the JBoss server, refer to the Administration and Configuration Guide for JBoss Enterprise Application Platform 6 onhttps://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

The table that follows shows an example of elements in a weblogic-application.xml file and the equivalent in standard Java EE descriptor files.

WebLogic weblogic-application.xml Element JBoss Equivalent
<application-param> element:
Maps to the web.xml <context-param> element:

Replace the WebLogic plan.xml Deployment Descriptor Configuration

The WebLogic plan.xml deployment descriptor file provides a way to target the application deployment for a specific environment, for example, development, integration testing, quality assurance, or production. In JBoss Enterprise Application Platform 6, you achieve the same outcome using property substitution. Using this technique, you pass the new values to the deployment descriptors based on the deployment environment. This topic describes how to change the target deployment environment in JBoss Enterprise Application Platform 6.

Use Property Substitution to Specify the Target Deployment Environment

1. Enable Property Substitution in the Server Configuration File

The <spec-descriptor-property-replacement> element in the ee subsystem of the server configuration file is used to enable or disable property substitution in the ejb-jar.xml and persistence.xml descriptor files. The <jboss-descriptor-property-replacement> element in the ee subsystem of the server configuration file is used to enable or disable property substitution in the jboss-ejb3.xml, jboss-app.xml, jboss-web.xml, *-jms.xml, and *-ds.xml descriptor files. To enable property substitution it must be set to true. This is the default value. The following is an example of the ee subsystem element configured to enable property substitution.


For more information about property substitution, refer to the Administration and Configuration Guide for JBoss Enterprise Application Platform 6 located on the Customer Portal at https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

2. Bind Strings for JNDI Runtime Mapping

For values outside deployment descriptors that change depending on the target environment, you can bind string values into JNDI and them map them into the application.
Assume the application's web.xml file contains the following resource reference:

To bind simple strings into JNDI, create a <simple> element in the naming subsystem of the server configuration file. The following is an example of the naming subsystem element configured for JNDI substitution.

Add an entry to the application's jboss-web.xml to map the global JNDI entry to the application's java:comp/env/ Environment Naming Context (ENC). The <resource-env-ref-name> element value must match the value specified in the web.xml and the <jndi-name> element must match the <simple> element name in the server configuration file.

Follow the same procedure to implement property substitution for other descriptor files.
For more information about how to manage the server configuration files, refer to the Administration and Configuration Guide for JBoss Enterprise Application Platform 6 located on the Customer Portal at https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

WebService.xml

WebLogic Webservice descriptor files
TODO: This section is not complete

*-jms.xml

WebLogic JMS descriptor file
TODO: This section is not complete

weblogic-ejb-jar.xml

WebLogic EJB descriptor

Security

Replace WebLogic Oracle Wallets

Weblogic administrators use wallets created by Oracle Wallet Manager to manage public key security credentials on application clients and servers. These wallets must first be converted to standard Java KeyStore (JKS) entries that can then be used to configure the credentials in JBoss Enterprise Application Platform 6.

1. Convert Oracle Wallet to JKS

Use the Oracle orapki command-line tool to convert the wallet to standard JKS keystore. Refer to the Oracle Wallet Manager documentation for details: http://docs.oracle.com/cd/E16340_01/core.1111/e10105/walletmgr.htm#ASADM10989.

2. Configure JBoss Enterprise Application Platform 6 to Use the Java KeyStore

Java KeyStores are configured in the security subsystem of the server configuration file. The schema is defined in the file:///JBOSS_INSTALL_DIRECTORY/docs/schema/jboss-as-config_1_4.xsd file. Be sure to replace JBOSS_INSTALL_DIRECTORY in the previous link with the actual path for your install. For details on how to configure the server to use keystores, refer to the chapter entitled Securing JBoss Enterprise Application Platform in the Administration and Configuration Guide for JBoss Enterprise Application Platform 6 located on the Customer Portal at https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

WebLogic Certicom-based SSL Implementation

Releases prior to WebLogic Server version 11g Release 1 (10.3.5) defaulted to the Certicom-based SSL (Secure Sockets Layer) implementation. The 11g release introduced an SSL implementation based on JSSE (Java Secure Socket Extension) and deprecated the Certicom-based SSL implementation. As of WebLogic Server version 12.1.1, JSSE is the only SSL implementation that is supported. JBoss Enterprise Application Platform 6 supports the JSSE implementation.

For instructions on how to implement SSL in JBoss Enterprise Application Platform 6, refer to Implement SSL Encryption for the JBoss Enterprise Application Platform Web Server in the Administration and Configuration Guide for JBoss Enterprise Application Platform 6 located on the Customer Portal at https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

WebLogic Security versus JBoss JAAS Security APIs

TODO: This section is not complete.

Understand Differences Between WebLogic and JBoss Implementations

Overview of JNDI Differences

JBoss Enterprise Application Platform 6 uses standardized portable JNDI namespaces. WebLogic applications must be changed to follow the standardized JNDI namespace convention. For more information about portable JNDI naming syntax, see the sections below on Portable JNDI Naming Syntax and JNDI Namespace Rules.

Migrate WebLogic JNDI Lookups to Use Portable JNDI Syntax

Replace WebLogic JNDI Lookup Code

In WebLogic, you create a Hashtable containing environment information such as provider URL, context factory, security principal and credentials. You pass this table as a parameter when you create the InitialContext. Then you lookup the Service using a prefix with the Service class name

This is an example of how code may look in WebLogic:

In JBoss, you instantiate the InitialContext with no argument and then look up the service using the portable JNDI lookup rules: java:global, java:app, java:module.

This is an example of what the code would look like in JBoss:

Portable JNDI Naming Syntax

There are four logical namespaces, each with its own scope. Three of the namespaces are used for portable JNDI lookups. The following table details when and how to use each namespace.

JNDI Namespace Description
java:global Names in this namespace are shared by all applications deployed in an application server instance. Use names in this namespace to find remote EJBs. The following is an example of a java:global namespace: java:global/jboss-seam-booking/jboss-seam-booking.jar/HotelBookingAction
java:module Names in this namespace are shared by all components in a module, for example, all enterprise beans in a single EJB module or all components in a web module. The following is an example of a java:module namespace: java:module/HotelBookingAction!org.jboss.seam.example.booking.HotelBooking
java:app Names in this namespace are shared by all components in all modules in a single application. For example, a WAR and an EJB jar file in the same EAR file would have access to resources in the java:app namespace.
The following is an example of a java:app namespace: java:app/jboss-seam-booking.jar/HotelBookingAction

You can find more information about JNDI naming contexts in section EE.5.2.2, "Application Component Environment Namespaces" in the "JSR 316: JavaTM Platform, Enterprise Edition (Java EE) Specification, v6". You can download the specification from here: http://jcp.org/en/jsr/detail?id=316

Portable JNDI Naming Syntax Rules

JBoss Enterprise Application Platform 6 has improved upon JNDI namespace names, not only to provide predictable and consistent rules for every name bound in the application server, but also to prevent future compatibility issues. This means you might run into issues with the current namespaces in your application if they don't follow the new rules.

Namespaces should follow these rules:

  1. Unqualified relative names like DefaultDS or jdbc/DefaultDS should be qualified relative to java:comp/env, java:module/env, or java:jboss/env, depending on the context.
  2. Unqualified absolute names like /jdbc/DefaultDS should be qualified relative to a java:jboss/root name.
  3. Qualified absolute names like java:/jdbc/DefaultDS should be qualified the same way as Unqualified absolute names above.
  4. The special java:jboss namespace is shared across the entire AS server instance.
  5. Any relative name with a java: prefix must be in one of the five namespaces: comp, module, app, global, or the proprietary jboss. Any name starting with java:xxx where xxx does not match any of the above five would result in an invalid name error.

Programmatic Login

WebLogic provides a proprietary ServletAuthentication class to perform programmatic login. In JBoss AS 7, you can use the standard Java EE6 Servlet 3.0 HttpServletRequest.login() method to perform programmatic login or you can define a <security-constraint> element in the web.xml file.

To enable programmatic login, you must replace the WebLogic proprietary code with one of the following:

  • You can add the following annotations to the Servlet class that performs the authentication.
  • If you prefer not to use the standard servlet, you can instead add a <security-constraint> element containing a dummy URL pattern to the web.xml file. This notifies JBoss to create a default Authenticator. Failure to create a <security-constraint> element in the web.xml file may result in the error message "No authenticator available for programmatic login".

The following is an example of a web.xml file with a <security-constraint> element:

If the application uses the WebLogic proprietary ServletAuthentication class for programmatic login, you must replace it with the standard HttpServletRequest login as follows:

WebLogic Transaction Manager JEE Transaction  Manager

TODO: This section is not complete

WebLogic JMX Lookups versus JBoss JMX Lookups

TODO: This section is not complete

Class Loading and Application Packaging

Archive Packaging and Assembly Rules

JBoss Enterprise Application Platform 6 uses a modular classloading system for controlling the class paths of deployed applications. This system provides more flexibility and control than the traditional system of hierarchical class loaders. This can simplify packaging of archives and eliminate the need to bundle Java EE 6 and other common classes. The following are general rules for assembly of archives or directories that are deployed to JBoss Enterprise Application Platform 6:

  • Archives may be nested within other archived deployments.
  • Extracted directories may be nested in extracted deployments.
  • Archives may be nested in extracted deployments.
  • Extracted directories may NOT be nested in archived deployments. You must recreate archives for the nested artifacts.
  • In WebLogic, an extracted WAR, EAR, or other archive can be deployed without the archive extension in the directory name. In JBoss, the extension must appear on the extracted directory name, for example myEnterpriseApp.ear or myWebApp.war.
  • The JBoss AS 7 installation includes Java EE 6, JBoss Logging, Hibernate, and other commonly used classes in the server install modules/ directory. You can also create custom dynamic modules to make third-party JARs and other resources available to all applications running on the server. Modules are only loaded when a deployment requests them and these JARs or classes should not be bundled within the application archives.
  • For web applications, it is generally better to avoid the use of a web.xml file if possible. If this file is required, it should be located under the root of the application WEB-INF/ directory.
  • If your enterprise application requires an application.xml file, it should be located under the META-INF/ directory in the root of the EAR.

Debug and Resolve ClassCastExceptions and ClassNotFoundExceptions

A ClassCastException can occur because a class is being loaded by a different class loader than the class it extends. It can also be a result of the same class existing in multiple JARs. A ClassNotFoundException can be a result of missing JARs or a mismatch of API versions. Due to the modular class loading system used by JBoss AS 7, you may need to modify deployment descriptors, remove JARs, or change the packaging structure of your EAR or WAR.

JBoss AS ships with a number of classes, or modules, that are commonly used by applications. These classes are located in the JBOSS_HOME/modules/system/layers/base/ directory and include all the application server provided APIs, the Java EE APIs, as well as other APIs such as JBoss Logging. If your WebLogic application packages a JAR that is also included in the server modules/system/layers/base/ directory, you may see a ClassCastException when you deploy or run your application. If your application needs a version of the classes that is different than the classes located in the JBOSS_HOME/modules/system/layers/base/ directory, you may see a ClassCastException or a ClassNotFoundException.

For more information about class loading and modules, refer to the chapter entitled Class Loading and Modules in the Development Guide for JBoss Enterprise Application Platform 6 on the Customer Portal .

Resolve ClassCastExceptions Caused by Duplicate JARs

Because JBoss AS 7 ships with a number of classes, or modules, that are commonly used by applications, packaging these common JARs with your application can result in a ClassCastException. For example, if you bundle the jstl.jar and standard.jar with the application archive, you may see a ClassCastException similar to the following:

To resolve this issue:

  1. Find the JBoss module that contains the class named by the ClassCastException. In this case, the jboss-jstl-api_1.2_spec-1.0.3.Final-redhat-2.jar can be found in the EAP_HOME/modules/system/layers/base/javax/servlet/jstl/api/main directory.
  2. Explicitly define the dependency in either the MANIFEST.MF file or in the jboss-deployment-structure.xml file. The following is an example of a jboss-deployment-structure file that defines the module dependency:
  3. Search the application archive to find all JAR(s) that are packaged with the application that contain the class named by the ClassCastException. In this case, the jstl.jar and standard.jar JARs were packaged in the lib/ folder of the application archive. Remove the duplicate JAR(s) from the application's packaged WAR or EAR file.
Resolve ClassCastExceptions and ClassNotFoundExceptions Caused by API Version Differences

If your application uses a version of an API other than the default API included in the main/ module of the modules/system/layers/base/ directory, you may see a ClassCastException or a ClassNotFoundException when you run the application.

For example, if your application uses JSF 1.2 instead of the default JSF 2.0, you may see you may see a ClassCastException or ClassNotFoundException like the following:

In this case, it cannot find the class javax.faces.FacesException due to a mismatch in API versions. The default JSF module for JBoss AS 7 is version JSF 2.0 and the application is using JSF 1.2. To resolve the mismatch, you must explicitly include the JSF 1.2 dependency and exclude the JSF 2.0 dependency.

To resolve this issue:

  1. Find the JBoss module that contains the class named by the ClassNotFoundException. In this case, there are 2 modules for the javax.faces.api classes. The default module for JSF 2.0 is located in the EAP_HOME/modules/system/layers/base/javax/faces/api/main directory and a module for JSF 1.2 is located in the EAP_HOME/modules/system/layers/base/javax/faces/api/1.2 directory.
  2. Explicitly define the dependency on the older JSF 1.2 version in the jboss-deployment-structure.xml file and exclude the default JSF 2.0 module as follows:
  3. Search the application archives and remove any jsf-api JARs from the packaged application.

Handle CMP Entity Bean Primitive Return Types

Some WebLogic applications with high performance requirements may use primitive types rather than Object types where the database allows NULL values. For example, if an Integer type database column that allows NULL values has not been initialized or contains no data, it will return NULL. WebLogic can be configured to return a primitive type for the NULL column value and will return 0 in this situation.

Because primitive types have lower memory requirements and better performance, you may want to preserve this behavior in JBoss Enterprise Application Platform 6.x. You could do this by adding a try/catch block around the database call and return a 0 in the case of a NULL, however, this approach will impact performance. A better solution is tell JBoss EAP 6.x to return an Integer, then handle the NULL value in the code, as in the following example.

Tell JBoss to Use Primitive Return Types

  1. Modify the application code.
    Assume the application has defined the following interface for the CMP entity bean:

    WebLogic returns a 0 in the case of a NULL value in the database, so you must modify the interface as follows to get the similar result in JBoss EAP 6.x.

  2. Modify the ejb-jar.xml descriptor file.
    The following is an example of the entity bean description in the ejb-jar.xml file before migration.

    You must change the <field-name> element from number to numberAsObject. This tells JBoss EAP to associate the getNumberAsObject() method with the database instead of the getNumber() method.

  3. Modify the jbosscmp-jdbc.xml descriptor file.
    The following is an example of the entity bean description in the jbosscmp-jdbc.xml file before migration.

    Change the <field-name> element from number to numberAsObject.

You should be aware that because primitive types are not Objects and can not be NULL, any updates will replace the NULL in the database column with 0. This is the same as the behavior in WebLogic.

Hibernate and JPA

Class loading in JBoss AS 7 is based on the JBoss Modules project. Some module dependencies defined by the application server are set up for you automatically. Other dependencies must be explicitly defined. By default, JBoss AS 7 assumes the use of Hibernate 4 with JPA applications and implicitly adds Hibernate 4 plus a few other dependencies to your application classpath. If your application currently uses Hibernate 3.x libraries, you may see ClassNotFoundExceptions or other Hibernate exceptions in the server log.

You have 2 choices:

  1. You can migrate your Hibernate 3.x application to use Hibernate 4. This is the recommended approach.
  2. If you do not want to update your application to use Hibernate 4, you can configure your application to use Hibernate 3.x in one of the following ways:
    1. You can package the Hibernate 3 libraries with your application.
    2. You can create a custom Hibernate 3 module.

The following sections describe how to do this.

Migrate Your Application From Hibernate 3 to Hibernate 4

Migrate Your Hibernate 3.3.x Application to Hibernate 4.x
  1. Map Hibernate text types to JDBC LONGVARCHAR
    In versions of Hibernate prior to 3.5, text type was mapped to JDBC "CLOB". A new Hibernate type, "materialized_clob", was added in Hibernate 4 to map Java String properties to JDBC "CLOB". If your application has properties configured as type="text" that are intended to be mapped to JDBC "CLOB", you must do one of the following:
    1. If your application uses hbm mapping files, change the property to type="materialized_clob".
    2. If your application uses annotations, you should replace @Type(type = "text") with @Lob.
  2. Review code to find changes in returned value types
    Numeric aggregate criteria projections now return the same value type as their HQL counterparts. As a result, the return types from the following projections in org.hibernate.criterion have changed.
    1. Due to changes in CountProjection, Projections.rowCount(), Projections.count(propertyName), and Projections.countDistinct(propertyName), the count and count distinct projections now return a Long value.
    2. Due to changes in Projections.sum(propertyName), the sum projections now return a value type that depends on the property type.
      1. For properties mapped as Long, Short, Integer, or primitive integer types, a Long value is returned;
      2. For properties mapped as Float, Double, or primitive floating point types, a Double value is returned.
        Failure to modify your application code could result in a java.lang.ClassCastException.
Migrate Your Hibernate 3.5.x Application to Hibernate 4.x
  1. Merge the AnnotationConfiguration into the Configuration
    Although AnnotationConfiguration is now deprecated, it should not affect your migration. If you are still using an hbm.xml file, you should be aware that JBoss AS 7 now uses the "org.hibernate.cfg.EJB3NamingStrategy" in AnnotationConfiguration instead of the "org.hibernate.cfg.DefaultNamingStrategy" that was used in previous releases. This can result in naming mismatches. If you rely on the naming strategy to default the name of an association (many-to-many and collections of elements) table, you may see this issue. To resolve it, you can tell Hibernate to use the legacy org.hibernate.cfg.DefaultNamingStrategy by calling Configuration#setNamingStrategy and passing it org.hibernate.cfg.DefaultNamingStrategy#INSTANCE.
  2. Modify the namespaces to conform to the new Hibernate DTD file names.
  3. Modify environment variables
    1. If you are using Oracle and using the "materialized_clob" or "materialized_blob" properties, the global environment variable "hibernate.jdbc.use_streams_for_binary" must be set to true.
    2. If you are using PostgreSQL and using the "CLOB" or "BLOB" properties, the global environment variable "hibernate.jdbc.use_streams_for_binary" must be set to false.

Configure Your Application to Use the Hibernate 3 Libraries

If you do not want to migrate your appliation to use Hibernate 4, you can try to resolve any issues using one of the following approaches.

Package the Hibernate 3.x JARs with the Application
  1. Copy the specific Hibernate 3.x JARs into the application's lib/ directory.
  2. Create a jboss-deployment-structure.xml file with the following content to tell the server to exclude the Hibernate 4 classes:
  3. Place the jboss-deployment-structure.xml file in either the META-INF/ directory or the WEB-INF/ directory if you are deploying a WAR, or in the META-INF/ directory if you are deploying an EAR.
In some cases this may result in ClassCastExceptions or other class loading issues due to the mixed use of the Hibernate versions. If that happens, you need to instruct the server to use only the Hibernate 3 libraries using the following procedure.
Create a Custom Module for the Hibernate 3.x Libraries
  1. Create a custom module for the Hibernate 3 libraries.
    1. Create a directory structure under the JBOSS_HOME/module directory to contain the Hibernate 3 files and JARs. For example:
    2. Copy the JARs from the Hibernate distribution to the {{JBOSS_HOME/modules/org/hibernate/3/} folder.
    3. Create a module.xml file in the JBOSS_HOME/modules/org/hibernate/3/ directory that describes the JARs and dependencies for the Hibernate 3 libraries. The following is an example of a module.xml file for Hibernate 3.6.6:
  2. Modify the persistence.xml to use the custom Hibernate module. Set the "jboss.as.jpa.providerModule" to "org.hibernate:3" as follows:

    The Java Persistence API (JPA) deployer will detect the presence of a persistence provider in the application and use the Hibernate 3 libraries.

  3. Create a jboss-deployment-structure.xml file with the following content to tell the server to use the Hibernate 3 module and exclude the Hibernate 4 libraries:
  4. Place the jboss-deployment-structure.xml file in either the META-INF/ directory or the WEB-INF/ directory if you are deploying a WAR, or in the META-INF/ directory if you are deploying an EAR.

Replace WebLogic Proprietary Features

WebLogic CommonJ Framework or WebLogic Work Manager API

The WebLogic CommonJ framework, sometimes referred to as the WebLogic Work Manager API, is not an official standard and, as such, is not supported in JBoss Application Server. JBoss instead supports the Java EE 6 standard WorkManager API (javax.resource.work.WorkManager). WebLogic applications that use the WebLogic version of the framework will need to replace this code.

The best approach is to implement a JCA Resource Adapter with the required business interface to replace the CommonJ code. The JCA Resource Adapter specification can be found here: JSR 322: JavaTM EE Connector Architecture 1.6 . The IronJacamar tool can help you get started writing a Resource Adapter. IronJacamar provides a WorkManager Resource Adapter in its test suite. Information about the WorkManager Interface can be found here: http://www.ironjacamar.org/doc/api/spec/1.7/javax/resource/spi/work/WorkManager.html.

Replace WebLogic Virtual Directories

WebLogic provides the ability to specify an alternate document root for files in a Web application using the <virtual-directory-mapping> element in the weblogic.xml proprietary descriptor file. JBoss AS 7 does not support this feature. If an application uses this feature, you must do one of the following:for JBoss to find the documents.

  • For JBoss servers running on Linux, you can set up symbolic links (symlinks) for the the documents defined with alternate roots.
  • You must modify the application packaging structure and move the files to the well-known standard Java EE 6 location.

Split Directories

WebLogic supports a split development directory environment. This directory layout contains both source and build directories. WebLogic uses both directories during deployment to find or generate artifacts. This model is meant for development purposes only. It is not recommended for production, so it should not impact your migration.

Replace WebLogic ApplicationLifecycleListener Code

The WebLogic ApplicationLifecycleListener abstract class is used to perform functions or schedule jobs at application server start and stop. The following table shows the four stages in the application lifecycle available for listener registration in WebLogic:

WebLogic Method Description
void preStart(ApplicationLifecycleEvent evt) Provides hooks for listeners before the application finishes initialization.
void postStart(ApplicationLifecycleEvent evt) Provides hooks for listeners after the application finishes initialization.
void preStop(ApplicationLifecycleEvent evt) Provides hooks for listeners when the application begins the shutdown process.
void postStop(ApplicationLifecycleEvent evt) Provides hooks for listeners after the application ends the shutdown process.

Replace Application Start and Stop Events

In JBoss Enterprise Application Platform 6, there is no equivalent to intercept the preStart or preStop processing, but you can use one of the following methods to achieve results similar to the postStart and postStop methods.

1. Create a ServletContextListener

The ServletContextListener class provides two methods that are analoguous to postStart() and postStop() methods in the WebLogic ApplicationLifecycleListener class. Since the code must access the context root of the application using the ServletContext, the servlet must be deployed to a WAR file. The following is an example of code that uses the ServletContextListener to perform tasks after application server start and stop:

2. Create a Singleton Stateless Session Bean

Create a singleton bean using the @Singleton annotation. Use the @Startup annotation to tell the container to initialize the singleton session bean at application start. Use the @PostConstruct annotation to specify the method to invoke at the start of the application lifecyle and the @PostDestroy annotation to specify the method to invoke at the end of the application life cycle. The following is an example of a stateless session bean:

WebLogic Proprietary Annotations

WebLogic provides its own proprietary servlet and filter annotations for dependency injection. If the application uses them, they must be replaced the standard Java EE 6 annotations. The following table contains a mapping of the most commonly used WebLogic annotations to the corresponding standard Java EE 6 annotation.

WebLogic Java EE 6 Equivalent Java EE 6 Import
@WLServlet @WebServlet javax.servlet.annotation.WebServlet
@WLFilter @WebFilter javax.servlet.annotation.WebFilter
@WLInitParam @WebInitParam javax.servlet.annotation.WebParam

Be sure to modify the attributes for the annotations to conform to the standard attribute names. Details about the attributes are listed below. For more information on the Java EE 6 servlet annotations, see the javax.servlet.annotation javadoc .

You must also remove the WebLogic imports and JAR.

Replace the Proprietary WebLogic @WLServlet Annotation

You must replace the proprietary WebLogic @WLServlet annotation with the standard Java EE 6 @WebServlet equivalent. Before you replace the code, you must understand how to map the attribute values. The following table shows the mapping of the WebLogic @WLServlet annotation attributes to the Java EE 6 @WebServlet equivalents.

WebLogic Attribute Name Java EE 6 Equivalent Description / Comments
String displayName String displayName Display name for the Servlet
String description String description Servlet description
String icon String smallicon -or-String largeicon The icon location
String name String name The Servlet name
WLInitParam[] initParams WebInitParam[] initParams Servlet initialization parameters
int loadOnStartup int loadOnStartup Whether the Servlet should load on server start
String runAs No equivalent attribute The run-as User for the Servlet. There are 3 options for replacement detailed below.
String[] mapping String[] urlPatterns or String[] value The Servlet URL pattern

The following is a list of options for replacement of the runAs attribute:

  1. Use the javax.annotation.security.RunAs annotation in the class file.
  2. Define the run-as element for the Servlet in the application's web.xml file.
  3. Define the run-as element in a application's {{web-fragments.xml} file. See sections 8.2.1 through 8.2.3 of the Servlet 3.0 specification for further information about web-fragments.

Here is an example of WebLogic code that uses the @WLServlet annotation:

Here is the equivalent code that uses the standard @WebServlet annotation:

Replace the Proprietary WebLogic @WLFilter Annotation

You must replace the proprietary WebLogic @WLFilter annotation with the standard Java EE 6 @WebFilter equivalent. Before you replace the code, you must understand how to map the attribute values. The following table shows the mapping of the WebLogic @WLFilter annotation attributes to the Java EE 6 @WebFilter equivalents.

WebLogic Attribute Name Java EE 6 Equivalent Description / Comments
String displayName String displayName Display name for the Servlet
String description String description Servlet description
String icon String smallicon -or-String largeicon The icon location
String name String name The Servlet name
WLInitParam[] initParams WebInitParam[] initParams Servlet initialization parameters
String[] mapping String[] urlPatterns or String[] value The Servlet URL pattern
No equivalent attribute DispatcherTypes[] dispatcherTypes The dispatcher types to which the filter applies
No equivalent attribute String[] servletNames The names of the servlets to which the filter applies

Here is an example of WebLogic code that uses the @WLFilter annotation:

Here is the equivalent code that uses the standard @WebFilter annotation:

Replace the Proprietary WebLogic @WLInitParam Annotation

You must replace the proprietary WebLogic @WLInitParam annotation with the standard Java EE 6 @WebInitParam equivalent. Before you replace the code, you must understand how to map the attribute values. The following table shows the mapping of the WebLogic @WLInitParam annotation attributes to the Java EE 6 @WebInitParam equivalents.

WebLogic Attribute Name Java EE 6 Equivalent Description / Comments
String name String name Name of the initialization parameter
String value String value Value of the initialization parameter
No equivalent attribute String description Optional description of the initialization parameter

Here is an example of WebLogic code that uses the @WLInitParam annotation:

Here is the equivalent code that uses the standard @WebInitParam annotation:

Oracle Fast Connection Failover (FCF)

JBoss EAP uses the JDBC API to access databases through JDBC 4.x compliant drivers supplied by database vendors. These drivers must adhere to the JDBC 4.x specification, although some vendors provide additional proprietary features. Fast Connection Failover (FCF) is one of these features. WebLogic applications can enable FCF for JDBC clients by setting the DataSource property FastConnectionFailoverEnabled to TRUE. This allows WebLogic JDBC applications to use connection failover capabilities provided by Oracle Database 10g. This functionality is vendor specific and not part of the JDBC standard specification.

Although JBoss EAP does not provide any direct support for vendor-specific functionality, many JDBC drivers provide support for their vendor's special features transparently to the application server to which they are deployed. For example, you can supply a detailed URL to the Oracle JDBC driver and the driver will provide transparent load-balancing and fail-over.

The followiung is an example of an URL that provides load-balancing and fail-over:

To gain access to Oracle's connection caching and FCF with Oracle RAC you must use Oracle Universal Connection Pool (UCP). Oracle's UCP has not been tested or certified by Red Hat is not supported in EAP 6.x.

WebLogic Production Redeployment

WebLogic Server includes a proprietary feature for production redeployment where the new version of the application is deployed while the older version is still running. The new version of the application accepts new requests while the older version finishes process requests already in process. Upon completion of the existing requests, the older version of the application is undeployed.

In JBoss EAP, you can achieve the same result in a clustered domain by creating a rollout deployment plan using the Management CLI. The following is an example of a CLI command to create a rollout plan in a clustered domain:

WebLogic Specific Oracle Datasources

TODO: section is not complete.

Evaluate the WebLogic Application

Examine the High-level Architecture of the Application

JVM Version

Frameworks

  • Portal
  • Rules Engine
  • Workflow
  • ESB

IDE (Eclipse Plugins)

Database

  • JDBC compliant drivers
  • Hibernate
  • Persistence frameworks

LDAP

Requirements for High-Availablity, Clusting, Failover, Caching

Third-party Libraries

External Systems

WebLogic Proprietary Libraries and APIs

Examine the Current Build Process

  • Consider conversion to Maven

Analyze and Understand the Application Code

Services and Components

Look for uses of the following components or services.

  • Cache
  • Clustering
  • Data sources - JDBC or proprietary
  • EJB
  • JMS - Queues, Topics, Messages to Migrate
  • JNDI
  • JTA
  • LDAP
  • Logging - Map WebLogic Debug options to the equivalent Java EE or JBoss classes for logging
  • MDB
  • Resource adapters
  • RMI
  • Security - JAAS, Encryption
  • Web Services

Proprietary WebLogic Features or Libraries

  • jCOM - Bridge to ActiveX
  • JSP tag extensions
  • WebLogic Helper Classes

Packaging and Deployment

Structure of the Archives

Deployment Descriptors and Plans

Evaluate the WebLogic Development Tools

Eclipse and Plugins

NetBeans

ADF

Data Migration

  • Database
  • LDAP
  • JMS

Determine Need for JBoss Modules

  • Third-party libraries
  • Library versions not provided with JBoss

Configure the Environment for the Migrated Applications

Install JBoss

Verify the Installation Using the Helloworld Quickstart

Migrate the Application

Execute the Migration Plan

Test

Move to Production

Tools and Tips

Debugging

Automated Tools

FAQs

Consulting Service

WebLogic Specific Oracle Datasources

TODO: section is not complete.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.