Previous Next vertical dots separating previous/next from contents/index/pdf

Key Differences for WebLogic Workshop 8.1 Users

As you've probably already noticed, Workshop for WebLogic 10.0 is quite different from WebLogic Workshop version 8.1. This topic lists a few of the key changes that you should be aware of if you've been using version 8.1.

Many Project Types are Now Represented Through Project Facets

Contents of an EAR File are Determined by Reference Rather than Containment

Java Files Now have .java Extensions Regardless of File Type

Page Flow Java and JSP Source Artifacts Now Reside in Separate Parts of a Project

A Web Project Need Not be Developed as Part of an EAR

Schema Projects have been Replaced by the XMLBeans Builder Facet

Shared Controls and XMLBeans Types Should be Kept in a Utility Project

Many Project Types are Now Represented Through Project Facets

Version 8.1 provided several project types you won't see in version 10.0. The functionality for many of these is provided through project facets. You add facets to add support for the functionality that your application will need. Through facets, Workshop for WebLogic projects can support more functionality than was supported in the version 8.1 web services, web, control, and Java projects.

Contents of an EAR File are Determined by Reference Rather than Containment

In version 8.1 you created an application that contained projects; projects were in the EAR because they were in the application, and the application represented the resulting EAR file. In version 10.0, you group projects in a workspace, but the workspace doesn't represent the EAR file. Instead, the EAR file is represented by an EAR project in the workspace, and other projects are included in the EAR file when the EAR project has a reference to them. See Applications and Projects for more information.

Note: You can have multiple EAR projects in a given workspace, each with its own EAR file result.

The 8.1 version appears on the left; the 9.2 version on the right.

The following shows EAR project properties referencing other projects to be included in the EAR file.

Java Files Now have .java Extensions Regardless of File Type

In version 8.1 web service, page flow controller, and other files had different extensions — such as .jws and .jpf. In the current version these files all have .java extensions.

Page Flow Java and JSP Source Artifacts Now Reside in Separate Parts of a Project

In version 8.1, a page flow's Java and JSP files were kept in the same project directory; in version 10.0 JSP files must be in a corresponding directory in the WebContent area. See Components of the Beehive NetUI Programming Model for more information.

The 8.1 version appears on the left; the 9.2 version on the right.

Generated Code and Build Output Now Reside in the Project Structure

In version 8.1, generated code and build output was in a parallel directory structure that lived outside user projects. In version 10.0, directories for these resources are within the project structure. These include the .apt_src and build directories, as well as the .xbean_bin and .xbean_src directories (which the XMLBeans Builder is enabled). These changes could impact:

A Web Project Need Not be Developed as Part of an EAR

In version 8.1 the built output of an application was always an EAR file. This meant that all projects in the application were deployed in an EAR. A version 10.0 workspace, on the other hand, need not have an EAR project; you can develop and deploy web projects outside the context of an EAR file.

The application.xml and weblogic-application.xml Files are No Longer Generated

In version 8.1 these files were generated from the WORK file, the file that represented an application. In version 10.0, you can edit these files. Note that the Eclipse Web Tools Platform (WTP) components of the IDE manage the representation of projects in these files.

Schema Projects have been Replaced by the XMLBeans Builder Facet

This version doesn't have a schema project type. Instead, you can enable automatic compilation of schemas and WSDLs by adding the XMLBeans Builder facet to the project that will contain them. Note that in this version creating a JAR file with generated Java types is a separate technique for using those types; the JAR file is not automatically generated by the XMLBeans Builder.

The 8.1 version appears on the left; the 9.2 version on the right.

Shared Controls and XMLBeans Types are Kept in a Utility Project

In version 8.1 you could use the control and control deliverable projects to develop control code that could be used across your application. Likewise, with a schema project for Java types generated from schema. In version 10.0 you put your control code or schemas into a utility project to share them across projects in the workspace. (Of course, you'd enable the XMLBeans Builder facet on the utility project for schema compilation. See Schema Projects have been Replaced by the XMLBeans Builder Facet for more.)

Related Topics

None.

 

Skip navigation bar   Back to Top