Oracle JDeveloper and Weblogic Workshop Interoperability

An Oracle JDeveloper How To Document
Written by Shaun O'Brien, Oracle
July, 2008

Introduction

With the acquisition of BEA, Oracle has added a significant amount of technical collateral to it's already impressive listing of potential choices for project implementation. This how-to will focus on the steps necessary to make use of the same codebase under the individual flagship development environments: namely Oracle JDeveloper and Oracle Workshop for WebLogic.

The codebase to be utilized is a sample application from the Workshop side of the world, the prototypical SUN Dukes Bookstore that can be accessed at the following url: jsf-bookStore.war.

About the Tools

Oracle JDeveloper: Oracle JDeveloper is an integrated development environment (IDE) for building service oriented applications using the latest industry standards for Java, XML, Web Services and SQL.

Oracle JDeveloper supports the complete development life cycle with integrated features for modeling, coding, debugging, testing, profiling, tuning, and deploying applications.

JDeveloper's visual and declarative development approach and the innovative Oracle Application Development Framework (Oracle ADF) work together to simplify application development and reduce mundane coding tasks, offering unparalleled productivity and a choice of technology stacks.

To read more, visit the JDeveloper home page

Oracle Workshop for WebLogic: Oracle Workshop for WebLogic extend Eclipse and Web Tools Platform with tools for Java, Java EE, Object Relational Mapping, Spring and Web Applications.

To read more about Workshop visit the home page.

The problem domain

The problem domain addressed in this paper is the situation where we're trying to work with a particular code base between the two environments described in the previous section. This is a common occurrence in environments where a tool has yet to be standardized on, or in this case where a new tool is introduced into an environment where a separate one already existed.

Most IDEs maintain metadata regarding the project structures they're maintaining. These are often independent of the code base itself. The Apache Foundation offers the Maven project that allows for managing the concept of a project independently as what is referred to as POM (project object model). This provides a way of managing and transferring between project structures utilizing a tool specifically built for that purpose. For more information on Maven feel free to visit the Apache Foundations homepage for Maven. For a basic introuction for Maven integration with JDeveloper refer to the following documentation. An in-depth view of this solution is outside of the scope of this how-to.

The Approach

The solution we will be utilizing here will be the import of a war file into the first environment, then showing how both tools can "share" that same source tree; illustrating where items need to be tweaked to solve individual issues in each environment. The solutions assume that you have already downloaded the war file listed in the introduction for use in project creation in each environment. Each of these solutions is also making the assumption we are working in a Windows environment.

Workshop

Open workshop by accessing the start menu and selecting the following from the all programs menu:

Once Workshop opens we select to create a new project and then to import source from the file menu as shown:

The import dialog should appear. Drill to expand the web selection and choose "WAR File" as shown below:

Once selected, you will be prompted for the location of the war file you're importing. By selecting this, the tool will read the manifest for the war file and fill in a default selection for a web project name as well as target runtime. Feel free to accept the defaults for these, or alter them to your individual needs.

When complete you should see something along the lines of the following in your project navigator:

To run the project select index.jsp and then select run from the run menu. The run dialog will show up as indicated below:

Click finish to deploy to the specified server. If everything is set up correctly the following page should appear in the IDE:

Feel free to explore the application to see the available functionality.

Oracle JDeveloper

To invoke JDeveloper, navigate on the file system to the folder you unzipped the download to and invoke jdeveloper.exe. If this is your first time invoking this JDeveloper installation it may ask you for the location of your jdk (Java Development Kit). Once you provide this, the tool will prompt you for the role you wish to use. Select the default role and the tool will open to the intro splash screen.

Creating a New Application:
From the application manager click on the pull-down and select new application. The following dialog will appear:

Simply select "Ok" here and on the next pop-up to accept the defaults.

Importing Source:
Next, right-click on the project from the application navigator and select "New" (or press Ctrl-N).

From the left-hand side of the gallery, select "Projects", then from the right-hand side, select "Project from Existing Source".

The following dialog will appear to assist in the import of source:

Click "Next".

Next in the wizard is the information relevant to the target project for this source. Feel free to name the project whatever you would like and designate a file system location for it (defaults to a subfolder of the active workspace under the [JDev install]\mywork\[Application Name]). For this example, we're going to name the project "bookstore".

Click "Next".

Now we are prompted for the location of the source we wish to reference from JDev. This should be located under your [Workshop home]\bea\user_projects\workspaces\default\[project name]. To add this source path to JDev we click the "Add" button to the right of the "Java Source Paths" pane.

A directory tree browser appears. Navigate to the appropriate source root, highlight it, and click "Select". You will be prompted with a confirmation dialog for importing the source. For this example we want the first selection, so uncheck the checked item (the second in the dialog) and click the checkbox behind the first one as indicated below, then click "Ok".

Change the default Package to "bookstore" and leave the "Copy Files to Project Directory" unchecked as we wish to reference the source externally so as to meet our use case of two IDE's working over the same source.

At this point, you can click "Finish" to begin the import.

Now JDeveloper takes over. It will locate the specified source, and create a local metadata refernce to it.

Let's do a compilation of the application. Right-click on the project name and select "Rebuild" as indicated below:

At this point you should have a compilation error such as the one displayed below:

Importing Libraries (Tag/Appliction):
There are a few steps we will need to take to acclimate this code to use within JDevloper. First of all, since we created this as a "blank" application and directly imported source, we're going to need to make JDeveloper aware of the appropriate libraries. We do this by accessing the project properties for the bookstore project. We can do this by double-clicking on the project name, right-clicking on the project name and selecting "Project Properties", or selecting the same from the Tools menu item. What we end up with is the following:

Let's start with the "JSP Tag Libraries" option from the left panel. Once you select it, you will be presented with a list of three options in the right hand pane for the differing scopes of the library visibility. In this case, we select "Local libraries" and click the "Add" button at the bottom of the pane. We end up with the following selection list:

Highlight "User", and click the "New" button from the bottom of the dialog. This will bring up a file chooser. Navigate to [Workshop home]\bea\user_projects\workspaces\default\[project name]\WEB_INF, select the bookstore.tld and click the "Open" button. This should return you to the selection list with "bookstore 0.03" added under User libraries. Click "Ok" to close the add libraries selection list.

Next, from the left side of the Project Properties dialog select the "Libraries and Classpath" selection, and click the "Add Library" button as shown below:

We get a libraries chooser like we saw for the tag library creation. Ctrl-click to multi select the following libraries:

• JSF
• JSP runtime
• JSTL 1.2
• JSTL 1.2 Tags

You should end up with the following:

Select the "Add JAR/Directory" button from the right. You will be prompted with a file chooser again. This time, drill down to the [Workshop home]\bea\user_projects\workspaces\default\[project name]\WEB_INF\lib folder and shift-click to select all of the libraries present here the click the "Select" button. You should end up with the following:

Click the "Ok" button.

Now let's try a rebuild, follow the directions specified earlier for how to do this. If you did everything correctly, you should see a set of error messages the look like the following:

Configuring HTML Root Directory:
The reason we are getting these errors is because the way the source we're using is structured it is not explicit where the document root is for the source. So we need to go in and tell JDeveloper directly where the other IDE placed the document root in the source tree. To do this, we invoke the project properties for bookstore again like we did earlier. Except this time we drill into "Project Source Paths" and select "Web Application" as our sub-selection.

Here we find the "HTML Root Directory" configuration property. Click on the "Browse" button and use the file chooser to navigate to: [Workshop home]\bea\user_projects\workspaces\default\[project name], click the "Select" button to close the file chooser, then click "Ok" to apply the changes and exit the project properties dialog. If you drill into the Web Content for the project you should also note that the jsp files now show up in our application navigator as show below:

Click the Save All icon to save your changes, and then recompile.

Fixing Application Legacy Issues:
Lastly, there is the syntax checking error we see above so to resolve this we examine the application. Based on the structure of the application it is discovered that within the web.xml it indicates that all pages include the prelude and coda jsps.

Examining the prelude.jsp we click on the source tab and find:

This means all pages will include the error page directive at the page level.

Going a step further and examining the actual error page itself in the errorpage.jsp we find:

Note that with the page directive in the prelude.jsp we've created a duplicate declaration on this page. To fix this we will go back to the prelude.jsp and remove the

Click the save all menubar icon and then rebuild the application again just like we did earlier.

You may get warnings such as the following: "Warning(35,8): class javax.faces.webapp.UIComponentTag has been deprecated" Don't be alarmed by these, it just is letting us know that we're running code that was created on older versions of the Java framework. By configuring the libraries it should locate the proper classes for us at runtime.

Running the Code:
So now let's run the code. Right-click on the index.jsp from the application navigator pane and select "Run" as shown below:

JDeveloper will start the bundled OC4J instance and deploy the app to it automatically opening a browser with the index page loaded into it. The page should look similar to the one below and identical to the one you loaded with Workshop.

Feel free to replicate the functionality you performed to test the application through Workshop to verify that it is indeed a successful migration of the code base.

Summary

In this how-to we explored a use case of utilizing common source code in two different development tools (Workshop and JDeveloper). As was seen even with simple examples there is the potential for the user to have to perform some handiwork to get the configurations just right but with a basic working knowledge of each tool these steps are minimal.

As each tool can "deploy" their working code to a war file, and import war files created by other toolsets; this leaves the ability to trade code between environments utilizing war files as the transport a simple and effective approach.

Should a more granular level of control over the project management be desired, the recommendation to explore Maven by the Apache foundation is likely the easiest and most widely supported option.