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

Changes During Upgrade from WebLogic Workshop 8.1 to version 10.0

This topic provides a list of the changes you're likely to see as you upgrade version 8.1 applications.

Project Model Changes Include Folder Hierarchies, File Extensions, Project Types

Javadoc-Style Annotations Have Been Replaced with Java 5 Annotations

Version 8.1 Features Updated in version 10.0

Version 8.1 Features Not Supported in Version 10.0

Scenarios Not Supported by Upgrade

Project Model Changes Include Folder Hierarchies, File Extensions, Project Types

Many of the changes from the version 8.1 to the version 10.0 project model are intended to align the model with broadly used Eclipse and Java conventions. If you've used other Eclipse-based IDEs, version 10.0 of Workshop for WebLogic should feel familiar.

Note: You might also be interested in the reading Key Differences for WebLogic Workshop 8.1 Users.

The following list summarizes the most significant differences between version 8.1 and version 10.0 project models.

Javadoc-Style Annotations Have Been Replaced with Java 5 Annotations

One of the largest aspects of this upgrade is the change from the Javadoc-comment style annotations used in version 8.1 to the Java 5 annotations supported for the version 10.0. For more information, see Upgrading Annotations. Most of the version 8.1 annotations have counterparts in version 10.0; for more information, see Relationship Between Version 8.1 and Version 10.0 Annotations.

Version 8.1 Features Updated in Version 10.0

These features have updated counterparts in version 10.0 and may be deprecated.

WS-Security Should Be Upgraded to WS-Policy

Impacts: Web services

Upgrade strongly recommended. In version 8.1, web service message-level security is managed using WS-Security (WSSE) policy files. In version 10.0 you should use Web Services Policy Framework (WS-Policy).

For information on manually updating to WS-Policy security policies, see Upgrading Security from from WS-Security to WS-Policy.

Security Settings for Service Control Specified in Multiple Locations

Due to changes in the web services security model, the means for specifying security characteristics through the version 10.0 service control differs from version 8.1. In version 8.1, you specified both security policies and values in a WebLogic Workshop WSSE policy file. In version 10.0, the means for specifying characteristics for these two aspects of security has been split into multiple locations.

For information on where security characteristics are now set, see Configuring Run-Time Message-Level Security Via the Service Control.

Roles Defined in web.xml No Longer Assumed to be the Principal Name in Upgraded Projects

In the course of upgrading your version 8.1 applications, you might find that some of your application's security-related characteristics differ between its behavior on the domain shipped with Workshop for WebLogic and the upgraded domain to which you redeploy it. This is because the "new" 9.x domain included with Workshop for WebLogic is not backward compatible, whereas the upgraded domain to which you deploy your upgraded application is (because it has been upgraded).

For more information and workarounds, see Resolving Issue of Unmapped Entries in web.xml.

Handling SOAP Faults with Wrapper Classes is Deprecated

Impacts: Web services

Supported but deprecated. Version 8.1 provided wrapper classes through which you could control the content of an outgoing SOAP fault, as well as APIs for retrieving content from an incoming SOAP fault. You can replace this functionality by using JAX-RPC to map SOAP faults to exceptions.

For more infomation, see Alternative to Wrapper Classes for Handling SOAP Faults.

Automatic Transaction Rollback for a Checked Exception is Deprecated

Impacts: Web services

Supported but deprecated. In version 8.1, the runtime would roll back a container-managed transaction if a checked exception was thrown from the application or runtime. In version 10.0, this behavior is supported with an annotation added (by upgrade tools during upgrade) to the web service source code.

For more information about this change and the workaround, see Upgrade Changes for Automatic Transaction Rollback.

Conversational Web Services Without START and FINISH Methods are Not Supported

Impacts: Web services

In version 8.1 it was possible to compile a "conversational" web service that did not have START or FINISH operations. In other words, you could annotate the web service class as conversational but not annotate any of its operations with conversation phase attributes. In version 10.0 a conversational web service must have both a START and FINISH operation in order to compile.

For more information, see Ensuring START and FINISH Methods for Conversations.

Combining Stateful and Stateless Operations in Web Services is Deprecated

Impacts: Web services

Version 10.0 supports web services that include both stateless and stateful operations, but the support is deprecated. In other words, in an upgraded conversational web service, stateless operations will be annotated with the deprecated annotation @Conversation(value = Conversation.Phase.NONE).

For more information, see Upgrade Changes for Web Services That Combine Stateful and Stateless Operations.

Same-Named Web Services Can Cause Deployment Error

Impacts: Web services

Due to a difference in the way versions 8.1 and 10.0 generate the default targetNamespace value for web services, you may enounter a deployment error if you have two or more web services with the same class name in an application. For web services in version 10.0, WebLogic Server uses the fully-qualified port name — which includes the web service's targetNamespace value — to bind resources it uses internally. As a result, the port name must be unique within an application.

For information on resolving the error, see Resolving Deployment Error for Same-Named Web Services.

Mismatch Between Operation Parameter Names and Names in WSDL Can Cause Web Service Failure

Impacts: Web services

After upgrading a web service in which one or more method parameter names do not match their corresponding names in the WSDL from which the web service was created, you will need to add a @WebParam annotation to each parameter.

For details, see Supporting Mismatch Between Operation Parameter Names and Names in WSDL.

Reliable Messaging Support Not Upgraded by Tools

Impacts: Web services

Workshop for WebLogic upgrade tools do not upgrade reliable messaging support (such as the @jws:reliable annotation) from version 8.1 to version 10.0. As noted in the version 8.1 documentation, that version's reliable messaging (RM) support was very limited and was not based on a specification that would be supported in future versions. You can manually upgrade reliable messaging support.

See Upgrading Reliable Messaging Support — Basic Instructions for high-level upgrade steps.

Version 9.0 and 9.1 WebLogic Server Web Services Might Need to Be Recompiled for Deployment in Version 10.0

Version 9.x doesn't support using the form-get and form-post message formats to receive messages sent from an HTML form. When upgrading web services that use these formats, you'll need to use another method for receiving data sent from a form in a web browser.

In other words, version 10.0 web services do not support message formats that do not include SOAP headers.

In version 8.1, the @jws:protocol annotation supported the following attributes and values:

These attributes have no counterparts in version 10.0 and there are no suggested workarounds. If you upgrade to version 10.0, upgrade tools will simply ignore a protocol setting that isn't supported.

Web Service from WSDL with xs:anyType Will Expect and Send Incorrect Message Payloads

Impacts: Web services

If you created a version 8.1 web service by generating it from a WSDL that specified xs:anyType instead of xs:any, the web service will expect and send incorrect XML payloads after upgrade to version 10.0.

You can ensure correct handling of xs:anyType by applying the @WildcardBindings annotation to the web service at the class level. For more information, see Ensuring Correct Handling of xs:anyType in Messages.

Service Controls Must Be Associated with a WSDL

Impacts: Web services, control use

While version 8.1 allowed a Service control to not be associated with a WSDL, the control must be associated with a WSDL in order for it to upgrade successfully.

For more information on associating a WSDL with the service control, see Associating a Service Control with a WSDL.

Service Controls Based on Abstract WSDLs are Not Fully Upgraded

Impacts: Web services

In version 8.1 it was possible to generate a service control from an abstract WSDL — that is, from a WSDL with no service definition. You could then configure the endpoint to call or listen on programmatically or by using annotations. However, WebLogic Server version 10.0 does not support abstract WSDLs. As a result, Workshop for WebLogic's upgrade tools are unable to upgrade a service control with the necessary annotations, leaving compiler errors in upgraded code. Likewise, if you try to generate a service control from an abstract WSDL in 9.x, you will receive an error stating that a service is required.

For more information and a suggested workaround, see Upgrading Service Controls that are Based on an Abstract WSDL.

Service Control Methods getEndPoint and setEndPoint are Deprecated

The ServiceControl.getEndPoint() and ServiceControl.setEndPoint(URL) methods are deprecated in version 10.0 and may be removed in a future version. New code requiring this kind of API should use ServiceControl.getEndpointAddress() and ServiceControl.setEndpointAddress(String), respectively.

For more detail, see Replacing Service Control Methods getEndPoint and setEndPoint.

JMS Control Properties Not Automatically Bound to Method Parameters by Upgrade

Upgrade tools do not fully upgrade JMS control support for binding control method parameters to JMS properties. In particular, the method parameters themselves must be annotated but aren't. You can ensure support for these bindings by manually adding the required annotations after upgrading your version 8.1 code.

For more information and an example, see Supporting Parameter Bindings for JMS Properties with the JMS Control.

Controls are Not Automatically Run Within the Scope of a Transaction

Impacts: Control use

In version 8.1, controls are automatically run within the scope of a transaction because they're run in the context of an Enterprise JavaBean. As Plain Old Java Objects (POJOs) in version 10.0, controls must be annotated with the @TransactionAttribute annotation for transaction support. During upgrade, upgrade tools will add this annotation.

For information on adding transaction support, see Enabling Automatic Transaction Support in Controls.

Row Set Functionality is Supported Through a Backward Compatible JdbcControl

Impacts: Control use

The standard Beehive JdbcControl (org.apache.beehive.controls.JdbcControl) in version 10.0, which corresponds to the version 8.1 Database control, does not support the version 8.1 "RowSet control" feature. To ensure that row set functionality is preserved during upgrade, the Database control is upgraded to the backward compatible JdbcControl (com.bea.control.JdbcControl) provided by BEA.

For more information, see Changes to Support Database Control Row Set Functionality.

Control Event Handler Exception Handling More Restrictive

Impacts: Control use

In version 8.1, control event handlers (known in that version as "callback handlers") could throw exceptions caught from the control by throwing the caught exception or a superclass such as java.lang.Exception. In version 10.0, if the event handler throws the caught exception, it must instead throw a proper subset of the throws clause declared for the control EventSet method.

See Upgrading Exception Handling in Control Event Handlers for information on working around the new requirement.

Upgrading Message Buffering in Custom Controls

In version 8.1 you could apply the common:message-buffer tag to a custom control's interface or implementation code. In version 10.0 this annotation's counterpart, com.bea.control.annotations.MessageBuffer, is supported only in the control interface code. To work around this change, you should remove the annotation from implementation code before upgrading the application.

Control and Web Services Context APIs Have Changed

Version 8.1 provided context APIs through which components such as web services (in version 8.1 JWS files) and custom controls could interact with their runtime environment. For web services, the location of JwsContext has changed, while some methods are no longer available. For controls, changes brought by the Apache Beehive control model to version 10.0 have meant that several APIs exposed by the version 8.1 control context classes are either exposed in different ways or are no longer relevant and so not available.

For a list of the affected APIs, see Handling Context API Changes.

Entity Beans are Not Automatically Run Within the Scope of a Transaction When the Transaction Isn't Specified

Impacts: Entity beans

In version 8.1, the EJB container would create a transaction for an entity bean if it ran in an unspecified transaction. In version 10.0, the default is not to create the transaction.

For information on ensuring the old default behavior, see Enabling Automatic Transaction Support in Entity Beans.

Ambiguity May Occur When Annotation Type References are Added to Upgraded Code

Impacts: Potentially any code that uses annotations

Unlike version 8.1, in version 10.0 annotations are Java types that must either be imported or fully-qualified in code. Because code using these types is being added to your code in order to upgrade from annotations in your version 8.1 code, there can sometimes be ambiguity when the added annotations have the same names as types your code may already have been using.

For information on how to remedy this ambiguity, see Resolving Amibiguity Related to Annotation Types.

Upgrading NetUI Tags to Beehive Tags Results in Changes to Some Tags and Attributes

Impacts: JSP files

Due to the differences between the version 8.1 NetUI tags and the Beehive NetUI tags, some changes might be made to JSP tags if you choose to upgrade them. For more information, see Changes When Upgrading from Version 8.1 NetUI JSP Tags to Beehive NetUI JSP Tags.

Packages for Fully-Qualified Type Names are Not Upgraded in JPF File Method and JSP Code

When a type name is fully-qualified outside a type import (Java or JSP), the type's package is not upgraded to the package used in version 10.0. For more information, including a workaround, see Fixing Package Names That are Not Upgraded in JPF File Method and JSP Code.

Upgrading NetUI Tags to Beehive Tags Sets the Default Expression Language to a Backward-Compatible Version

Impacts: JSP files

A backward-compatible version is set as the default for the upgraded application because it is more permissive than the version 10.0, giving you an opportunity to migrate your version 8.1 code. For information on changing the default expression language, see Changing the Default Expression Language Used by JSP Tags.

Impacts: JSP files

Upgrading NetUI Tags to Beehive Tags Does Not Fully Account for Expression Language Requirements

Impacts: JSP files

If you request it, upgrade tools will migrate your NetUI JSP tags to Beehive JSP tags. This includes migrating from the NetUI expression language syntax to the syntax of the Beehive JSP expression language. However, note that expressions in the Beehive JSP expression language are unable to bind to public fields, as was the case with NetUI expressions. For a full upgrade to Beehive JSP tags, in other words, you must manually add get* and set* accessors where public fields were used.

For more information on these differences, see Changing Code to Support the Expression Language in Beehive NetUI JSP Tags.

Some PageFlowController and FlowController Methods Made Protected Instead of Public

To enhance application security, some public methods in org.apache.beehive.netui.pageflow.PageFlowController and org.apache.beehive.netui.pageflow.FlowController have been changed so that they're protected. This change means that these methods can no longer be invoked as bean properties from within JSP pages.

For more information, see Details: Some PageFlowController and FlowController Methods Made Protected Instead of Public.

FlowController.getRequest Method Can No Longer Return a ScopedRequest Instance

In version 8.1, the return value of the FlowController.getRequest method could be cast to a ScopedRequest when running in the WebLogic Portal environment. In version 10.0, to improve performance the Beehive page flow APIs retrieve a ScopedRequest instance differently. If your portal code makes a call to this method, you will need to manually upgrade the code to avoid a ClassCastException.

For more information and a suggested fix, see Upgrading from getRequest Method Calls to Retrieve a ScopedRequest Instance.

XMLBeans Package is Changed; Schemas Must be Recompiled to Regenerate Types

Impacts: Code that uses XMLBeans, including web services, controls, JSP files, Enterprise JavaBeans

During upgrade, the package for types in the XMLBeans API will be changed from com.bea.xml to org.apache.xmlbeans. In addition, if your version 8.1 application included a schemas project (a project that supported automatic compilation of schemas into XMLBeans types), that project will be migrated to a version 10.0 project through which the schemas continue to be compiled into XMLBeans types.

XML Schemas are Validated More Strictly

Impacts: XML schemas

Version 10.0 uses a more strict schema validator than was used in version 8.1. The upgrade process does not repair invalid schemas that might have been considered valid in version 8.1. Because of this, you should ensure that schema validation is on when working with schemas whose validity is important.

XQuery Implementation Used by XMLBeans Updated from Working Draft 16 to Working Draft 23

Impacts: Code that uses XMLBeans and XQuery, including web services, controls, page flows, Enterprise JavaBeans

The older XQuery implementation is deprecated, but supported in this version for backward compatibility. Queries based on the older implementation will be kept, but a special XmlOptions parameter will be added to specify that the old implementation should be used.

One exception is XQuery use in JSP files, which is not updated by upgrade tools. You will need to make changes manually. For more information see Updating XQuery Use to Support Upgraded XQuery Implementation.

Custom Ant Build Scripts are Not Upgraded by the Upgrade Tools

Impacts: Build processes

If you created custom Ant build scripts in version 8.1, you must manually upgrade them for use with version 10.0. You can migrate your modifications after upgrading your application by re-exporting your Ant build file, then merging in your modifications.

Note: Unlike version 8.1, version 10.0 does not support building your application with Ant from within the IDE. You must export the build file and execute targets from the command line.

In version 10.0 use the following steps to export an Ant build file:

  1. Right-click any file in your application, then click Export.
  2. In the Export dialog, click Workshop Ant Script, then click Next.
  3. In the Ant Script Generation dialog, under Project, select the workspace project for which you want to export an Ant script.
  4. Under Ant Script Generators, select the WebLogic Server script you want to generate.

    Note that to generate a script designed to build projects for use on WebLogic Server, you should choose a generator that has "(WebLogic Server)" in its name. Do not select "Java Project Build Script," which compiles JAVA files but is not designed to build projects for WebLogic Server.

  5. Under File Name, enter (or browse for) the location for the Ant script file you are about to generate.
  6. Click Finish.

You can edit the generated script file to support the customizations you want.

When running targets in the generated Ant script file, you will need to pass to the script a parameter value indicating the workspace's location. You can do this in one of two ways using the -Dworkspace command-line option. You can also specify the location of a workspace metadata file:

ant -buildfile build.xml -Dworkspace=c:\workspaces\MyWebServices\workspace.xml

To generate the metadata file, you export it as described above for the Ant script file. In the Export dialog, select Workspace Metadata for Workshop Ant Scripts. In subsequent dialogs, select the projects whose metadata you want the file to include, along with specific variable values you want. Note that as you change workspace settings — such as by adding a new project to an EAR — you will need to re-export the metadata file.

You can also give the workspace directory as the argument:

ant -buildfile build.xml -Dworkspace=c:\workspaces\MyWebServices

IDE Extensions Based on the Version 8.1 API are Not Supported

Impacts: IDE extensions

Version 10.0 of Workshop for WebLogic is based on Eclipse, which has its own model and API for developing extensions — known to Eclipse users as plug-ins. Version 8.1 extensions are not upgraded. If you wrote extensions based on the version 8.1 model, you need to rewrite them if you want to keep that functionality. If you used extensions based on the version 8.1 model, you need to find parallels in the Eclipse extension set.

For more information on Eclipse plug-ins, see Eclipse help in this documentation or online.

Configuration Settings are Now Exposed Through WebLogic Administration Console or WLST

Impacts: Configuration

WebLogic Workshop version 8.1 provided several files you could use to configure the run-time environment for applications you built with WebLogic Workshop. These files are not included in version 10.0:

Many of the properties set through them are now configurable using the WebLogic Administration Console, or are scriptable with the WebLogic Server Scripting Tool (WLST). For example, see the WebServiceMBean at the MBean reference for information some values you might have set through

For more information about the administration console, see Overview of the Adminstration Console in the WebLogic Server documentation. For more about WLST, see WebLogic Scripting Tool.

Some Version 8.1 Wildcard Import Statements Will Break Compilation on Version 10.0

Because the Workshop for WebLogic upgrade tools don't upgrade wildcard import statements, some of these statements will generate errors on version 10.0 because their libraries are not present there. In some cases, you can fix these by replacing them with their version 10.0 counterparts.

After upgrade, you might find that some import statements with wildcards have been changed to reflect their nearest parallel in version 10.0.

Version 8.1 Features Not Supported in Version 10.0

These features are no longer supported. The following describes functionality that version 8.1 supported, but which must be rewritten in order for upgraded code to work in version 10.0.

XQuery Maps Are Not Supported

Impacts: Web services, Service controls

Version 10.0 doesn't support XQuery maps, a version 8.1 feature through which you could use XQuery to reshape XML messages entering and leaving a web service operation. This change impacts not only the XML shapes supported by the web service itself, but creates a mismatch between the web service and service controls generated from it or its WSDL file. One workaround is to rewrite your code so that its WSDL matches the existing WSDL shape without the use of maps.

Note: The lack of support for XQuery maps does not mean that XQuery itself is not supported. You can still execute XQuery expressions using the XMLBeans API. For more information on upgrade changes impacting this API, see Updating XQuery Use to Support Upgraded XQuery Implementation.

For more information, see General Steps for Replacing XQuery Maps.

java.util.Map Can Not Be Returned from Web Service Operations

Impacts: Web services

Version 8.1 supported returning instances of java.util.Map from web service operations. The runtime provided a WebLogic Workshop-specific serialization of the Map to and from XML. The schema for that serialization was included in the WSDL for the Web Service. In version 10.0, java.util.Map instances can no longer be returned from web service operations.

For a suggested workaround, see Replacing the Use of java.util.Map as a Web Service Operation Return Type.

Multiple SOAP Versions are Not Supported for Bindings Defined in a Web Service

Impacts: Web services

Unlike version 8.1, version 10.0 doesn't support using multiple SOAP versions for bindings defined in a web service. When upgrading, you'll need to manually edit any web services that use more than one SOAP version so that they use only one.

Version 8.1 Implementation of SOAP 1.2 is Not Supported

Impacts: Web services

Version 8.1 included a SOAP 1.2 implementation that was based on a working draft of the SOAP 1.2 specification. The version 10.0 implementation is based on the final version of the specification, and so differs from the older implementation. To ensure compatibility for clients of a SOAP 1.2 web service you created with version 8.1, you should rebuild the client using a WSDL generated from an upgraded (version 10.0) version of the web service.

For more information on generating a WSDL, see Upgrading from Version 8.1 Implementation of SOAP 1.2.

Non-SOAP XML Message Format Over HTTP or JMS is Not Supported

Impacts: Web services

If you have version 8.1 web services that use the non-SOAP XML format over HTTP or JMS, you must change your web service on version 10.0 so that it either uses the SOAP protocol or some alternative.

For information on changing the message format in web services, see Details: Non-SOAP XML Message Format Over HTTP or JMS is Not Supported.

Handlers Not Supported for Callbacks

Impacts: Web services

In version 8.1 the @jc:handler and @jws:handler annotations included a callback attribute that specified handlers to process SOAP messages associated with callbacks; version 10.0 does not include callback-specific handler support. For the counterparts of these annotations in version 10.0, see Upgrading Annotations.

form-get and form-post Message Formats are Not Supported to Receive Data

Impacts: Web services

Version 10.0 doesn't support using the form-get and form-post message formats to receive messages sent from an HTML form. When upgrading web services that use these formats, you'll need to use another method for receiving data sent from a form in a web browser.

For more information, see Details: form-get and form-post Message Formats are Not Supported to Receive Data.

Multiple Protocols for Web Service Operations is Not Supported

Impacts: Web services

While version 10.0 supports multiple protocols at the web service level, it does not continue the version 8.1 support for multiple protocols at the operation level. When upgrading, if a single web service has operations that use different protocols, you'll need to create separate web services and divide the operations among them so that a single protocol is used in each service.

For information on making this change, see Upgrade Changes for Multiple Protocols in a Web Service.

Mixed Operations with Document and RPC SOAP Bindings Will Result in Namespace Differences

Impacts: Web services

If a version 8.1 web service includes one or more operations that use the RPC SOAP binding and one or more operations that use the document SOAP binding, then after upgrade types generated for those operations will be placed into different namespaces. This will be different from the version 8.1 web service itself, in which the types were in the same namespace. A WSDL generated from the upgraded web service will differ from the version 8.1-generated WSDL.

For more information, including a workaround, see Resolving Namespace Differences from Mixed Operations with Document and RPC SOAP Bindings.

Deprecated UseWLW81BindingTypes and WLWRollbackOnCheckedException Annotations are Added to Upgraded Code

Supported but deprecated. Upgraded web service and Service control code will include the @UseWLW81BindingTypes and/or @WLWRollbackOnCheckedException annotations applied at the class level. Even though these annotations are deprecated, they are required in order to support clients that used the version 8.1 code.

Web Services or Service Controls Whose WSDLs Define Multiple Services is Not Supported

Impacts: Web services

In version 8.1 it was possible to have a web service (JWS) or Service control whose WSDL defined multiple services. The web service or control would represent only one of these services. When upgrading such code to version 10.0 upgrade will fail. To ensure that upgrade succeeds for this code, you should edit the WSDL so that it defines only the service that is represented by the JWS or Service control.

Multiple <wsdl:import> Elements are Not Supported

Even though it was supported for WSDLs associated with version 8.1 service controls, in version 10.0 multiple occurrences of the <wsdl:import> element is not supported in the same WSDL. For example, you might have used one import to get WSDL portions of the WSDL and another import to get XSD portions for needed types.

More information and a workaround is available at Upgrading WSDLs with Multiple <wsdl:import> Statements.

Types in 1999 Schema Namespace Not Supported

Version 8.1 supported using types in the 1999 schema namespace for service controls and web services generated from WSDLs that used the types. Because version 10.0 does not support types in this namespace, you will need to manually migrate the WSDL to the 2001 namespace.

For more information, see Updating WSDLs from 1999 Namespace to 2001.

EJB Control Security Annotations Not Upgraded by Upgrade Tools

Due to the how the EJB control works (which differs from other kinds of controls), the upgrade tools do not automatically upgrade security annotations used in an EJB control. You can work around this difference by manually editing the EJB control extension file to include the needed methods and annotations.

For more information and an example, see Upgrading Security in EJB Controls.

EJB Control getJNDIName and setJNDIName Methods Invoked Differently

Impacts: Control use

Differences from the getJNDIName and setJNDIName methods exposed from the version 8.1 EJB control will cause errors in upgraded code. In version 8.1, these methods were exposed as EJBControl.getJNDIName and EJBControl.setJNDIName; in version 10.0, they are exposed from a build-time-generated control bean class as getJndiName and setJndiName (note the case difference also).

For information on fixing method invocation code, see Upgrading EJB Control getJNDIName and setJNDIName Method Invocations.

JDBC Control Does Not Support "All" array-max-length Value for Query Results

The version 8.1 database control supported getting all rows for a query by specifying "all" as a value for the @jc:sql array-max-length attribute. The version 10.0 JDBC control does not support this value; instead, specify a numerical value. This change is not automatically made by upgrade tools.

For more information, see Replacing "All" Requests for Database Control Results.

Control Factories are Not Supported

Impacts: Control use

Version 10.0 does not support control factories, a version 8.1 feature in which multiple control instances could be created at run time from a single control. If your code uses control factories, you'll need to replace the functionality with an alternate solution.

For a suggested alternative, see Replacing Control Factory Functionality.

JMS Controls Can't Be Used to Receive Messages

Impacts: JMS controls

In version 10.0, a JMS control can't be used to receive messages. In upgraded code, you can work around this by developing a message-driven bean (MDB) to receive the messages or by invoking a web service using asynchronous request-response.

JMS Control sendJMSMessage Method Takes a Different Message Parameter Type

Version 8.1 of the JMS control took a JMSControl.Message type as a parameter for its sendJMSMessage method; in version 10.0 the method takes an instance of javax.jms.Message. For a full upgrade, you must change your code accordingly.

For more information, see Upgrading JMS Control sendJMSMessage Method Invocations.

Multiple Calls to TimerControl.start Method Have No Effect

Impacts: Control use

In version 8.1 it was possible to call the timer control's start method multiple times, without error, to start the timer; however, the onTimeout callbacks did not necessarily correspond to the separate calls to the start method. The version 10.0 timer control simplifies the API by disallowing multiple calls to the start method. Calls to the start method when the timer control is still running will have no effect.

Controls Used in a Page Flow Can't Receive External Callbacks

Impacts: Control use, page flows

In version 9.x custom controls used from a page flow can't receive external callbacks. In version 8.1, you could write a custom control that received callbacks from controls nested within it, such as service controls. By exposing a polling interface from your custom control, your page flow code could then retrieve responses received from the callbacks. This functionality is not supported in version 10.0.

In upgraded code, you can substitute for this functionality by replacing your custom control with a web service. For more information on the version 8.1 feature and suggested version 10.0 workarounds, see Providing Support for Callbacks from a Page Flow.

Some Version 8.1 Context and Control Context Events and APIs are Not Available in Version 10.0

Impacts: Web services, control creation

These are events and APIs that were either considered low usage or were not general enough in nature to be included in the Beehive controls runtime.

In situations such as with the the logging API, you can modify your applications to make direct use of standalone APIs or WebLogic Server-provided APIs (such as the logging API from Apache Commons). However, there is currently no workaround for situations where the APIs were closely associated with the runtime container.

ControlException.getNestedException Method is No Longer Available

Impacts: Control use.

The version 8.1 com.bea.control.ControlException featured a getNestedException method that is not included on its Beehive counterpart, org.apache.beehive.controls.api.ControlException. Code that calls this method will represent a compilation error after upgrade. Because this method merely delegated to the getCause method of the Throwable class — which the Beehive ControlException class extends — working around this change is as simple as changing the getNestedException call to getCause.

Version 8.1 Control Annotation Definitions are Not Upgraded

Impacts: Control creation

Version 8.1 custom control annotation definitions are not upgraded to version 10.0. The means for defining annotations is based on the Java 5 annotations model. To upgrade controls written for version 8.1, you must rewrite the annotations definition in keeping with the new model.

See Upgrading Custom Controls Featuring Custom Properties for more information.

Co-Location of Controller File and JSP Files is Not Supported

Impacts: Page flows

Version 8.1 supported a project hierarchy in which the Controller file (Controller.jpf) and JSP files could be put into the same directory. This is not supported in version 10.0. During upgrade your project hierarchy will be changed so that the Controller file is no longer co-located with JSP files.

For more information, see Upgrade Changes for Co-Location in Page Flows.

IDE Sync Features Not Included in this Version

The version 8.1 IDE included a set of features through which the IDE kept related files in sync. For example, after generating a ServiceControl from a WSDL, changes to the WSDL would cause the IDE to automatically re-generate the ServiceControl to match. This functionality is not supported in the version 10.0 IDE.

For suggested workarounds, see Keeping Files in Sync in the Absence of IDE Support.

Scenarios Not Supported by Upgrade

Custom Tags That Extend NetUI Tags are Not Supported

If you created custom JSP tags in version 8.1 by extending NetUI tags, your tags will not be upgraded by Workshop for WebLogic tools. Extending NetUI tags was not supported. Note that if you elected not to migrate NetUI tags to Beehive tags, your tags may build within the application, but may not work as expected.

Likewise, extending Beehive JSP tags in version 10.0 is not supported.

IDE Erroneously Shows an Error When Variable Declarations are Made in an HTML Start Tag

The version 9. 2 IDE incorrectly displays an error for code in which a variable declaration is made in an HTML start tag; the code is actually valid at run time. For example, in the following anchor tag the <%=s%> code using the String variable is flagged by the IDE as unresolved, but is actually valid.

Fixing Erroneous IDE Error for Variable in an HTML Start Tag

Related Topics

Overview: Upgrading from WebLogic Workshop 8.1


Skip navigation bar   Back to Top