Build a Java Application with Eclipse, Spring, and Oracle WebLogic Server

Oracle Enterprise Pack for Eclipse makes developing applications for the Spring Framework and/or for Oracle WebLogic Server easier. Here's how.

by Dustin Marx

Published February 2010

Oracle Enterprise Pack for Eclipse (OEPE) is a set of certified plug-ins designed for easy integration with the core Eclipse IDE to provide additional support for developing and deploying enterprise Java applications with the Spring Framework and Oracle WebLogic Server. In this article, I'll offer an overview of this support.

Installing Oracle Enterprise Pack for Eclipse

Oracle Enterprise Pack for Eclipse 11g can be downloaded separately and added to an existing Eclipse installation via the normal plug-in mechanisms. An especially convenient alternative is to download a complete version of Eclipse that comes with OEPE already configured. Once the plug-ins have been installed, or the complete version of Eclipse with OEPE already configured has been installed, the availability of these plug-ins can be verified by selecting the About Eclipse Platform option from the Help menu.

Figure 1

Each of the five square buttons with rounded corners represents an installed plug-in feature. The two features of particular interest for this article are the two features with rightmost buttons. The Spring IDE feature button is the furthest right feature button and the button to its left represents the OEPE plug-ins.

Oracle Enterprise Pack for Eclipse with the Spring Framework

The Spring Framework has become a widely used framework for generation of enterprise Java applications because of the many advantages that it offers. However, there are some aspects of working with the Spring Framework that can be improved through the use of the Spring IDE plug-in that is included with Oracle Enterprise Pack for Eclipse.

One of the challenges that developers new to the Spring Framework encounter as they learn about the framework is understanding and working with the XML-based Spring configuration files. The Spring IDE functionality included with OEPE provides several features that make working with Spring XML more intuitive. These features include a “Design” view of Spring XML configuration files, Spring element and attribute completion, and detection and notification of any non-compliant entries in the Spring context files.

With OEPE, you can create a new Eclipse project as a Spring project. The following two images show how to select a Spring project from the New Project Wizard and how to add specific details on the Spring project when creating it.

Figure 2

Figure 3

The wide range of capabilities offered by Spring Framework mean that there are many choices for Spring configuration. It can be difficult to learn and remember how various XML elements, attributes, and namespaces are related in a Spring configuration file.

The next image shows how to select the wizard for creating a new Spring definition bean.

Figure 4

Once the wizard for a “Spring Bean Definition” is selected, two steps in the creation wizard allow the name of the Spring context file to be specified and allow the applicable Spring Framework XSD-based schemas to be selected. These two steps are shown in the next two images.

Figure 5

Figure 6

The image above shows the many XSD namespaces that Spring supports. The namespace that is nearly always useful in Spring context files for declaring the Spring beans (the “beans” namespace) is pre-selected as indicated in this screen snapshot. The “context,” “util,” and “p” namespaces are also commonly used in Spring applications.

Assuming that those are selected and that the other settings shown in the previous screen snapshots are used, the generated Spring context file looks like that shown in the next screen snapshot of the Source tab in Eclipse.

Figure 7

Using the Spring Bean Definition wizard allows the Spring context configuration file to be generated correctly and without mistyping. As the preceding screen snapshot demonstrates, the namespaces selected in the wizard are included and the appropriate schemaLocations are provided.

The preceding image indicates that the Spring IDE provides a Design tab. This tab allows one to see a Spring XML configuration file as a series of two-column rows rather than as raw XML. A particularly useful feature of this Design view is the ability to select applicable attributes, child elements, and other portions of the Spring configuration file from a list of valid possibilities.

The next image demonstrates the Spring IDE displaying the available child elements for the Spring configuration root “beans” element. The choices are listed by right-clicking on the element’s name in the Design view.

Figure 8

It is useful to be offered the possible child elements of the “beans” element. Without this functionality, one must remember or discover what possible child elements will work and must be sure not to mistype those entries. The preceding image also shows an option to add attributes as well. Adding attributes to the Spring configuration element with this mechanism offers the same advantages as adding child elements with this approach.

There may be times when it is more convenient to edit Spring configuration files directly in the XML source than in the Design view. In such cases, another advantage of the Spring IDE is the auto-completion of Spring context elements and attributes. This auto-completion offers the same advantages as the Design view in terms of only presenting viable options.

The next screen snapshot demonstrates the suggested child elements offered when I started to type a new element with the opening “<”. Several valid choices are offered and the currently selected option, the “bean” element, has its documentation (from the defining XML Schema) displayed to help the developer decide if that is the appropriate choice. The inclusion of Spring’s XSD documentation means that a developer can stay focused on the IDE and not need to move back and forth between the IDE and the relevant XML Schema file.

Figure 9

With the drop-down selections offered by the Design view and the auto-completion drop-down selections offered in the Source view, it is much easier to generate a correct Spring context file. However, the benefits the Spring IDE provides for improving the configuration experience do not stop here. When an unrecognized value is specified in a Spring configuration file, the improper syntax is highlighted in red to mark improper syntax in Java code. The next screen snapshot demonstrates the indication that the “bean” child element was misspelled (“been”).

Figure 10

The Spring support provided with OEPE includes support for Spring 2.5 features. For example, one of the namespaces that can be selected for inclusion with the Spring Bean Definition wizard is the JMS namespace that was first available in Spring 2.5. The next screen snapshot shows that the 2.5 namespace is the only version other than the non-versioned default that can be selected for JMS inclusion. Other namespaces have 2.0 or even earlier versions in addition to 2.5 versions.

Figure 11

Many of the Spring IDE features covered so far are largely possible due to the XML Schema Definitions (XSDs) that constrain the available elements and attributes and their relationships with one another.

In the next screen snapshot, the Spring IDE reports two errors and one warning associated with my Spring context file. Validation of the Spring configuration file occurs during a Save.

Figure 12

The first error reports that there is “No setter found for the property ‘another’ in class ‘dustin.examples.MainApplication’.” This indicates that the specified class does not have a method called setAnother(String) that accepts a String. Because no error is reported for the line above it, we can also safely assume that there is a method called setCalculator(SimpleCalculator) implemented for that class.

Within the Spring configuration file, a warning states “Referenced bean ‘calculatorBeen’ not found” and this indicates that no defined bean exists with an ID of “calculatorBeen.” Fixing the spelling to “calculatorBean” will make this warning go away the next time the file is saved because there is a “calculatorBean” bean defined in the file. It makes sense for this type of problem to be a warning rather than an error because it is possible that a bean not defined in this file is set in a different context configuration file that is expected to be on the classpath. Indeed, the Spring Framework 2.5 documentation states that the Spring development team generally prefers the approach of providing multiple Spring context configuration files to an application context constructor without explicit linkage between these files.

There are tremendous benefits to having the IDE validate Spring configuration against available Java classes. The Spring Framework’s dependency injection adds significant deployment flexibility, but comes at the cost of requiring runtime dependency checking instead of compile-time dependency checking. The Spring IDE support just discussed allows developers to continue to enjoy the deployment flexibility while also allowing developers to recognize broken or missing dependencies without having to actually run the application.

The Spring Explorer is useful for viewing all the Spring-specific constructs in a project. The next screen snapshot demonstrates the Spring Explorer. Any of the elements shown can be clicked on and the main window focus will shift to the source code for the selected element.

Figure 13

The Spring Beans Search tool is another useful feature available for development with the Spring Framework. When trying to debug a problem related to dependencies or other items contained in Spring context configuration files, the Spring Beans Search tool limits its search to the Spring context files. A second advantage of this tool is that it provides alternate methods for finding desired configuration information. As the screen snapshot below demonstrates, one can search by bean name, by Java class backing the bean, by contained property name, and for child beans and referencing beans. This search tool is especially helpful when working with large enterprise applications with a high number of configuration files.

Figure 14

Oracle Enterprise Pack for Eclipse includes Spring Framework 2.5.6 bundles. This makes it easy to use Spring 2.5 new features such as the added JMS namespace, easier annotation-based JMX, easier annotation-based auto-wiring, easier annotation-based component detection, and easier JDBC access.

One extremely useful characteristic of the Spring Framework is its adaptation of diverse technologies that implement the same general functionality to a common perspective. A particular example of this is Spring’s support for Data Access Objects (DAO). The Spring Framework provides abstract DAO classes specific to certain underlying data access technologies. Developers can extend these Spring-provided DAO classes to have easy access to the applicable Spring functionality for that particular type of data access. The advantage of this DAO approach is that the specific characteristics of a particular data access technology are isolated to the implemented DAO class.

Although the Spring Framework provides the DAO base classes to alleviate developers from much of the functionality associated with data access using a particular technology, developers must still extend these provided abstract classes. Oracle Enterprise Pack for Eclipse addresses this issue by providing a mechanism for automatically generating these Spring-based DAO classes.

The “Generate Spring ORM Classes” feature must be run from a project supporting the Spring Facet. If your project is configured to support Facets, you can right-click on the project’s name in the Project Explorer window, select Properties, select Project Facets, and then set up the Spring Facet by clicking on the checkbox next to Spring Facet. Note that the Spring Facet requires the use of other facets and you may need to configure these first if they are not already configured in your project. The following image shows the facet configuration window with the requirements for using the Spring facet.

Figure 15

As the above screen snapshot demonstrates, use of the Spring facet requires a Java facet for J2SE 5 or newer and additional facets. For this example, use the “Utility Module” facet.

When the Java 6 facet has been applied and the Utility Module facet has been applied, the Spring facet can be selected. The following screen snapshot demonstrates the results of clicking on the Spring facet.

Figure 16

The last screen snapshot shows that additional configuration was still necessary. This was indicated with the icon featuring an “X” within a red circle and the underlined text link Further configuration required…. In addition, the Apply button is disabled at this point.

To enable the Apply button, one can click on the link Further configuration required… and select the appropriate Spring Framework libraries. The wizard screen for selecting the appropriate Spring Framework libraries is shown in the next screen snapshot. For Spring 3.0, SpringIDE bundles the spring libraries to easily add to the project. Older versions of Spring can be downloaded directly through the facet configuration screen.

Figure 17

Once the Spring Framework libraries have been configured, Apply the changes to complete the facet configuration for the project.

Figure 18

To demonstrate how to generate ORM classes, this example uses the Java Persistence API (JPA) as the ORM implementation. An easy way to enable the JPA technology on a project is by adding additional facets. This action is indicated in the next screen snapshot.

Figure 19

For this example, JPA entity classes are generated from Oracle database tables, which I created with the following SQL:

create table address

(

id number(19) primary key,

street varchar2(255),

city varchar2(255)

);

create table person

(

id number(19) primary key,

name varchar2(255),

address_id number(19)  references address(id)

);

Here are the resulting database tables as viewed in Oracle SQL Developer:

Figure 20

With the database tables already in place and the JPA facet configured, it is easy to generate JPA entity classes. Using the wizard to create these entity classes from database tables involves right-clicking on the project name in the Project Explorer and selecting New→Other→JPA→Custom Entities. This wizard window appears like the one shown in the next screen snapshot.

Figure 21

When the JPA Custom Entities wizard is selected, a wizard window is provided that prompts for selection of tables from which the entities should be generated.

Figure 22

Clicking on Next after selecting the appropriate tables leads to the opportunity to set up or modify associations as shown in the next screen snapshot.

Figure 23

After clicking on the Next button, the database tables and their associations are set. The next wizard screen allows for options to be set related to the generation of the entity classes.

Figure 24

As the warning note states at the top of this wizard screen, it is best not to use the default or unnamed package for the entities that will be generated from the database tables. In other words, a package should be declared into which the generated entity classes will go. This specification of a destination package for the generated entity classes is shown in the next screen snapshot.

Figure 25

As the screen snapshot above demonstrates, the generated entity classes will be placed in a package called otn.examples. With the package selection and other general entity characteristics set, individualization of entity classes is supported next. The next wizard screen in shown in the following figure.

Figure 26

In the above screen snapshot, the configuration for the Address entity class was set. However, this wizard screen supports setting configuration at column level and for each class to be generated. Clicking Finish here leads to the actual generation of the entity classes based on the specified database tables. The next figure shows these generated entity classes in the Project Explorer window.

Figure 27

The JPA entity classes use field-based annotations because that is what I specified during the generation process. You can find the source code for these two generated classes (Address.java and Person.java) in the sample code download for this article.

Once the project is configured to use the Spring Facet, right-clicking on the project’s name in the Project Explorer window will lead to the option to Generate Spring ORM Classes (under New >Other). Selecting this option is demonstrated in the next screen snapshot.

Figure 28

When the Generate Spring ORM Classes option has been selected, that wizard’s first screen appears as shown in the next figure.

Figure 29

Clicking on the button with the green + sign leads to the wizard screen shown in the next figure.

Figure 30

Several key pieces of information regarding the desired generated ORM DAO classes can be specified here. The top Service Name field’s entry is used to automatically name the service and DAO interfaces and classes (although these can be changed by hand if desired). Once the Persistent Unit is selected, valid choices for entity classes will be displayed. In this case, these will be the classes generated with the JPA Custom Entity generated previously demonstrated.

The Exception Class is the type of exception that will be included in a throws clause for the methods of the service interface and the service class. The packages for the service and DAO interfaces and classes are also shown on this wizard screen. A partially populated version of this screen specific to our example is shown next.

Figure 31

Once the initial information for generation of ORM service and DAO objects has been defined, the next screen in this wizard prompts for implementation strategy. The default is Plain JPA, but I select the alternative using Spring’s JpaTemplate and JpaDaoSupport classes for this example.

Figure 32

Clicking on the Finish button leads to the generation of the ORM classes and interfaces based on the provided entity classes. The newly generated classes appear in the Project Explorer as shown in the next figure.

Figure 33

As the view of the Project Wizard above indicates, I placed the generated ORM service and DAO classes and interfaces in the otn.examples.services package. The generated DAO implementation class is specific to the ORM implementation as evidenced by the inclusion of JPA in its class name (PeopleJPADao). It is also the class that directly extends Spring’s JpaDaoSupport class, a helper class Spring provides for easier use of its JpaTemplate class.

In addition to the JPA-specific DAO class, the wizard also generated an interface for that DAO class that is not ORM implementation specific as well as a service class and its interface that are also independent of ORM implementation choice. The generated source code for each of these (IPeopleService.java, PeopleSpringService.java, IPeopleDao.java, and PeopleDao.java) are available in the sample code download.

The Spring Framework provides JpaDaoSupport to make it easier for developers to apply JpaTemplate in their code. However, the functionality provided by OEPE as just demonstrated goes well beyond this to automatically generate classes and interfaces that support the basic CRUD (Create/Read/Update/Delete) on the entity classes. The generated classes and interfaces also nicely separate ORM implementation-specific details from the more general service class and even from the DAO’s interface.

The following class diagram depicts the classes and interfaces generated with the OEPE Spring ORM generation wizard and their relationship to the Spring-provided JpaDaoSupport. When viewing this class diagram, keep in mind that JpaDaoSupport is intended to make it easier to use Spring’s JpaTemplate.

Figure 34

In this class diagram, the Spring-provided JpaDaoSupport has a title bar with green background. This is provided by Spring with or without use of OEPE. All of the other classes and interfaces shown above would normally need to be hand-written by a developer, but OEPE has generated them automatically based on a few characteristics provided in the “Generate Spring ORM Classes” wizard.

One of the explanations for the wide popularity of the Spring Framework is the simplicity it has brought to enterprise Java. The OEPE support for Spring Framework makes the Spring Framework even easier to apply to enterprise applications. There are situations when developers need features of a fully Java EE compliant application server. OEPE provides similar benefits for deploying applications to Oracle WebLogic Server as its does for the deploying to the Spring container. OEPE even provides support for easier integration of the Spring Framework and Oracle WebLogic Server.

Oracle Enterprise Pack for Eclipse with Oracle WebLogic Server

Oracle Enterprise Pack for Eclipse offers several features that make it easier to deploy to and use Oracle WebLogic Server. These features include design support for WebLogic-specific descriptor files (weblogic.xml and weblogic-application.xml), support for Oracle WebLogic Server’s FastSwap feature, support for WebLogic Server’s Shared Libraries feature, and support for multiple versions of Oracle WebLogic Server.

Associating an Instance of WebLogic Server with Eclipse

To take advantage of OEPE’s Oracle WebLogic Server features, it is useful to associate one or more instances of Oracle WebLogic Server with the IDE. This can be done by selecting New→Other→Server as shown in the next image.

Figure 35

When you double-click on the Server item or select Server and click on the Next button, the wizard then presents a list of servers you can define. The next screen snapshot demonstrates how this might look.

Figure 36

The snapshot shown above lists several versions of Oracle WebLogic Server under the grouping “BEA Systems, Inc.” The wizard checks the instance of Oracle WebLogic Server that you associate with the IDE against the version you select here, so you cannot select “BEA WebLogic Server v10.0” and hope to actually use WebLogic Server 10.3 or 11g with the IDE. Instead, you should look for the grouping under “Oracle” and select the appropriate version of Oracle WebLogic Server from that group. The next screen snapshot demonstrates this.

Figure 37

From this screenshot, we see that there are multiple Java EE server implementations available from Oracle, including versions of OC4J (Oracle Containers for Java EE) and the two newer versions of Oracle WebLogic Server (10g R3 and 11g R1).

The “at localhost” portion of the “Server name” field indicates that this will be a local instance of Oracle WebLogic Server. OEPE also provides remote deployment and debugging facilities to develop against a remote Oracle WebLogic Server instance. The desired host is specified in the top field of the same wizard window in which I select the version of Oracle WebLogic Server that I want to use.

There is even more to the wizard window shown in the last image. There is a link called Download additional server adapters. This is an example of use of the Library Provider Framework. In this case, it allows an Eclipse user to download support for additional servers to be associated with Eclipse. For example, this could be used to download Eclipse-ready support files for future versions of Oracle WebLogic Server as they are made available.

Creating a Web Project

With an instance of Oracle WebLogic Server associated with the IDE, we can now use that server instance for any Eclipse projects that depend on a Java EE server. The easiest way to generate a project for a web application is to right-click in the Project Navigator and select New→Project. Then, in the Project wizard window, select Dynamic Web Project under the Web folder. This is demonstrated in the next screen snapshot.

Figure 38

When I select Dynamic Web Project, the first screen in that Dynamic Web Project creation wizard appears as shown in the next image.

Figure 39

The Oracle WebLogic Server 11g R1 instance I set up previously is shown here as my “Target Runtime.” The 2.5 selection refers to the Servlet 2.5 specification. In this case, selecting the “Default Configuration for Oracle WebLogic Server 11gR1” Facet Preset will add some basic Facets for Web application development. There are several other options available here, including options for automatic JSF and Web services support.

Clicking on Next brings up the Web Module configuration screen in the Dynamic Web Project creation wizard.

Figure 40

The default context root is simply the name of the project. In the example shown above, I changed the context from “SimpleWebProject” to “simpleWeb”. The above sample uses the default settings for the Web project’s content directory and source code directory in place. Finally, checking Generate deployment descriptor option will create the required web.xml deployment descriptor and optional weblogic.xml deployment descriptor..

Clicking Finish will create the project along with the additional project resources and configuration files as seen below:

Figure 41

From this screen snapshot of the Project Explorer, we see that the web.xml and weblogic.xml descriptor files have been generated as we requested in the project creation wizard.

Creating an Enterprise Application Project

Dynamic Web applications can be deployed directly to Oracle WebLogic Server without use of an Enterprise Application Project (EAR Project). However, when an Enterprise Application Project is desired, it is easily created by right-clicking in the Project Explorer window and selecting New→Enterprise Application Project. A wizard will appear as demonstrated in the next screen snapshot.

Figure 42

As the above screen image demonstrates, we can again select our previously defined Oracle WebLogic Server 11gR1 instance as the “Target Runtime” and we can specify the Java EE specification version (“EAR version”) as 5.0. We are also going to use the Default Configuration for Oracle WebLogic Server 11gR1 again.

When I click the Next button on the “New EAR Application Project” wizard page, I am then taken to a wizard page on which I can select which Java EE modules this Enterprise Application Project should include. An EAR Project is not intended as an actual project with its own source code and artifacts, but is instead a container project that contains other Java EE projects. In this case, because I had previously generated four other applicable projects, these four projects are listed for possible inclusion in this EAR project. This is shown in the next image.

Figure 43

As the screen image above demonstrates, I have chosen to have the dynamic Web project previously created included in this EAR project. I have also specified that I would like an EJB project to be included. I have checked the option to have the deployment descriptors generated as well. When I click on the Finish button, the wizard finishes and generates an Enterprise Application Project as shown in the next screen image.

Figure 44

We can see in this image that the newly created EAR Project contains the two generated descriptor files: Java EE standard application.xml and WebLogic Server extensions-specific weblogic-application.xml.

Editing the Java EE and Oracle WebLogic Server Extensions Descriptor Files

Just as the inclusion of Spring IDE with the OEPE download simplified Spring Framework configuration, OEPE also provides easier configuration of applications that use Oracle WebLogic Server extensions. The Java EE specification allows compliant servers to provide extensions through server-specific configuration files. In the case of Oracle WebLogic Server, this file for Web applications is called weblogic.xml. Similarly, the configuration file for Oracle WebLogic Server extensions for Enterprise Applications (EAR) is called weblogic-application.xml. OEPE provides editors for these two specific files that make creating and maintaining these Oracle WebLogic Server-specific descriptor files much easier.

For editing the standard Java EE descriptor files web.xml and application.xml, Eclipse and OEPE provide the same table-based “Design” view as demonstrated earlier for editing Spring configuration files. This view is useful because it allows the developer to select child elements and other portions of the XML file from drop-down lists. As with the Spring configuration work, this reduces the chances of mistyping entries or using non-supported XML elements or attributes. An example of this taken from the web.xml file is shown next.

Figure 45

By using this feature, one not only quickly sees what valid options are available, but it is much less likely that any mistyping errors will occur in the element tags and their attribute names. Similar support to that just shown for the web.xml file is also provided for the standard application.xml file.

The editors for the standard Java EE deployment descriptor files are very helpful, but the editors for the Oracle WebLogic Server extensions deployment descriptors are even more developer-friendly. The “Descriptor” tabs for these editors are more sophisticated than the table-based approach used in the “Design” tabs of the previously demonstrated editors.

When creating the SimpleWebProject, I specified that the Target Runtime is WebLogic 11gR1. This particular piece of information is not something one specifies in the server-independent web.xml file. However, it is desirable to have this server version information in the WebLogic-specific weblogic.xml file. The initial weblogic.xml file generated with the Dynamic Web Project wizard appears as shown in the next code listing.

  10.3.1

  simpleWeb

The project creation wizard was helpful because it added all of the necessary namespace specifications to the root element of this file, associated this descriptor with the specified version of Oracle WebLogic Server, and provided the Web application’s context. However, there are many additional options that can be specified in this descriptor file. As with the editing of the Spring configuration files, one way the editor can be used is to use XML element completion in the Source tab to select an allowable XML element. This is demonstrated for the weblogic.xml file in the following screenshot.

Figure 46

In the previous example, typing in an opening “<” sign leads to a pop-up window demonstrating the allowable elements. In this case, I selected the wls:fast-swap element. While this approach works and is definitely better than needing to remember the element names and needing to ensure they are typed in correctly, the Descriptor tab can provide an even easier method for specifying this FastSwap option.

The next screen snapshot demonstrates how user-friendly the WebLogic Web Application Deployment Descriptor “Descriptor” tab is. In this case, the FastSwap element is specified.

Figure 47

When I return to the Source tab, I see that the FastSwap information specified with the checkbox and two easy text fields has now been added to the weblogic.xml source.

"1.0" encoding="UTF-8"?>

"http://www.bea.com/ns/weblogic/weblogic-web-app"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd

http://www.bea.com/ns/weblogic/weblogic-web-app

http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd">

10.3.1

simpleWeb

   

true

5

5

The weblogic-application.xml file generated by the Enterprise Application Project creation wizard is shown next.

"1.0" encoding="UTF-8"?>

"http://www.bea.com/ns/weblogic/weblogic-application"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/javaee_5.xsd

http://www.bea.com/ns/weblogic/weblogic-application

http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd">





webapp.encoding.default

UTF-8

Like the weblogic.xml file, this can be edited directly in the Source view and element and attribute completion can be used to make this direct source editing easier. Even better, the OEPE-provided editor for weblogic-application.xml provides a Descriptor view of this WebLogic-specific file similar to that provided for weblogic.xml. The following screen snapshot demonstrates how a description can be easily added using this tool. Notice also that I have selected the Enable Spring extension checkbox.

Figure 48

When the weblogic-application.xml file is edited using this Descriptor view, the source code is changed as shown next.

"1.0" encoding="UTF-8"?>

"http://www.bea.com/ns/weblogic/weblogic-application"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/javaee_5.xsd

http://www.bea.com/ns/weblogic/weblogic-application

http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd">







webapp.encoding.default

UTF-8



org.springframework.jee.interfaces.SpringComp

onentFactory

The weblogic-application.xml file now includes the entries we specified in the Descriptor view, but it was certainly more straightforward to add these entries via the Descriptor view than to the source code directly.

Because I selected the Enable Spring extension checkbox in the “General” section of the weblogic-application.xml editor, OEPE added the wls:component-factory-class-name element to the descriptor file with a reference to the org.springframework.jee.interfaces.SpringComponentFactory. This option allows Oracle WebLogic Server to use the Spring Framework for dependency injection (DI) and aspect-oriented programming (AOP) features beyond what is supported in the Java EE specification. The referenced SpringComponentFactory class is provided as part of the Spring Framework project called Pitchfork that implements JSR 250 (“Common Annotations for the Java Platform”). The editor for weblogic.xml descriptor files offers the same ability to specify use of this Spring Framework extension in web applications.

Specifying Shared Libraries

Support for Shared Libraries is another Oracle WebLogic Server-specific feature that OEPE makes easier to use. The Shared Libraries concept allows multiple applications deployed to Oracle WebLogic Server to make use of the same libraries. The use of Shared Libraries in an Enterprise Application Project is specified via the weblogic-application.xml descriptor file. As previously demonstrated, this file can be easily edited with the Descriptor view of the file’s editor. The next screen snapshot shows this Descriptor view of the editor while being used to specify a Shared Library.

Figure 49

The top right corner of the Descriptor view provides a one-sentence description explaining that this setting allows specification of libraries that will be shared between applications. Clicking on the link under that description (Add shared library references…) leads to the screen shown next.

Figure 50

In the example above, libraries that can be selected to be shared across deployed applications include JavaServer Faces (JSF), multiple versions of MyFaces, and multiple versions of JavaServer Pages Standard Tag Library (JSTL). In situations where a library other than the ones provided above is needed as a shared library, the Manage WebLogic Shared Libraries… link can be used to browse for other libraries that can be shared. This screen is shown next.

Figure 51

The Add… button can be used to add other libraries that can then be specified as shared libraries for multiple applications deployed to Oracle WebLogic server.

When a particular library is selected as a Shared Library, it appears in the Descriptor view of the weblogic-application.xml descriptor file editor as shown in the following snapshot.

Figure 52

In the example shown immediately above, the JSTL 1.2 library was selected as a shared library. The actual source code for this inclusion is shown next.

"1.0" encoding="UTF-8"?>

"http://www.bea.com/ns/weblogic/weblogic-application"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/javaee_5.xsd

http://www.bea.com/ns/weblogic/weblogic-application

http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd">







webapp.encoding.default

UTF-8





jstl

1.2

true



org.springframework.jee.interfaces.SpringCom

ponentFactory

The library-ref element and its sub-elements specify to Oracle WebLogic Server that the JSTL 1.2 library should be used as a shared library. The advantage of using a shared library in this manner is that the library does not need to be included in each individual WAR or EAR file deployed to the server.

FastSwap

In the earlier example on specifying Oracle WebLogic Server-specific extensions with the weblogic.xml file, I used specification of FastSwap as an example. This useful feature allows a developer to “swap” a class definition with certain allowable changes in a deployed application (JAR, WAR, or EAR in expanded form) without needing to redeploy the entire application. Although FastSwap does not compile the new class, Eclipse supports the ability to compile when the file is saved. Without automatic compilation upon saving and FastSwap, it can be frustrating to go through the entire Java EE redeployment process, especially for a minor change. Because Oracle WebLogic Server understandably only supports FastSwap in development mode, its specification and use in Eclipse via OEPE is apropos.

Conclusion

The Spring Framework and Oracle WebLogic Server are two of the best known and widely used products in the world of enterprise Java. Oracle Enterprise Pack for Eclipse makes developing applications for the Spring Framework and/or for Oracle WebLogic Server easier. OEPE and the included Spring IDE allow developers to spend less effort researching and remembering Spring-specific and Oracle WebLogic Server-specific configuration details. OEPE and its included Spring IDE also dramatically improve the correctness of configuration at compile time so that fewer errors must be discovered at runtime.

Source: http://www.oracle.com/technology/pub/articles/marx-oepe-spring.html