|
|
This document contains information on the following subjects:
Workshop for WebLogic continues the ground-breaking innovation of the 8.1 release, providing powerful tools for developing WebLogic Platform applications.
Here are some of the most important new features in Workshop for WebLogic:
Workshop for WebLogic is built on the widely used Eclipse Platform. Instead of the proprietary IDE framework used in previous releases, version 9.2.3 uses the Web Tools Platform 1.0.
Version 9.2.3 supports Apache Beehive, an open source framework for web applications. Support for Apache Beehive includes:
Version 9.2.3 includes first-class support for Java Server Faces technology, including:
The same ground-breaking web service support in version 8.1 has been carried forward in version 9.2.3, now built on JSR-181. Web service support includes:
As with version 8.1, version 9.2.3 supports the use of annotations to simplify the development of complex components. While most of the functionality of the version 8.1 annotations carries forward into this version, the version 9.2.3 annotations are based on the JSR-175 standard, new in Java 5. Workshop for WebLogic continues to provide tool support to keep the use of annotations simple, including a property editor for intuitive annotation editing.
Version 9.2.3 makes it easy to upgrade your version 8.1 applications. Upgrade support includes:
Workshop for WebLogic supports blended application architecture combining the best of open source and BEA's innovative technologies. Blended application offers:
Workshop for WebLogic is targeted toward the iterative development experience rather than production deployment. As such, a number of features that work correctly in a standalone (development) server environment will not function as expected in a clustered deployment.
Important — Development and testing of applications using this release of Workshop for WebLogic should be done using standalone server environments.
For more information on platform support, including hardware and software requirements, see the Supported Platforms web site.
Updated documentation is available at the Workshop for WebLogic e-docs site.
Table 1 lists the known limitations found in Workshop for WebLogic.
|
When an upgrade fails the new files are not reverted to their original state but may not be fully upgraded. For example, the file extension may have been changed to .java, but annotations may not have been translated to Workshop for WebLogic version 9.2.1 style. Note that the original source files are not altered.
|
|||
|
Description: The tagid attribute on netui tags isn't unique across pageflow portlets after migrating to the Beehive tags unless you add a scriptContainer tag. Adding the scriptContainer tag forces a unique tagId to be generated.
|
|||
|
If a user selects a version 8.1 domain in the New Server wizard, a hyperlink is displayed to allow user to launch the Domain Upgrader. Upon successfully upgrading the domain, the state of wizard is not refreshed under some circumstances. The old error message on the top of the wizard and the upgrade hyperlink remain, and the Next button is not enabled.
|
|||
Javadoc attachments for Workshop for WebLogic libraries can be broken if Workshop for WebLogic is not installed into the default directory under <BEA-HOME>
During installation there is an option to specify the directory into which Workshop for WebLogic version 9.2.1 is installed. If you specify something other than the default (which is "workshop92"), then the Javadoc for Workshop for WebLogic code such as the service control or timer control cannot be found by the IDE. Thus, actions like Shift-F2 to show the documentation for the classes will not work
Workaround: Add Javadoc attachments to the jars contained in those libraries manually. For example, to add a javadoc attachment to the base Workshop for WebLogic controls jar, go to Windows > Preferences > WebLogic > J2EE Libraries. Select weblogic-controls-1.0 and click Edit. Expand each jar in the Classpath Contribution: tree, right-click the Javadoc location node, and select Edit. Next set the Javadoc location path: to <BEA-HOME>/<your-workshop-dir>/workshop4WP/docs/api, where <your-workshop-dir> is the non-default workshop directory name you entered during install.
|
|||
|
In some cases while debugging an application the source for the JDK classes cannot be found, and will result in a "Source Not Found" page for the class.
Workaround: The workaround is to add a Source attachment manually. This can be done either at the workspace preference level, or if already running a debug session it can be done right there.
If not yet in a debug session, go to the Windows > Preferences > Java > Installed JREs preference page. Select the jdk150_04 JRE and click Edit. Deselect "Use default system libraries" on the Edit JRE dialog. Open the node for rt.jar and select the Source attachment node. Click Edit, then select External File... and navigate to <BEA-HOME>/jrockit90_150_04/ and select src.zip.
|
|||
|
When debugging an application on the server, occasionally when saving code changes, you may see the following displayed in the debugger window on one or more of the threads: "(may be out of sync)". If this occurs, you will need to republish your application in order to resync the server with the code you have just entered. This is a known problem with Eclipse 3.1.
|
|||
|
Due to a problem in Eclipse, some JSP tags (such as <auth:login> and <portlet:actionURL>) and variables declared from JSP tags are marked as containing an error when they are actually correct; although no error actually exists, Eclipse will not publish (deploy) the application.
Workaround: If this situation occurs, you must turn off JSP validation before publishing. Leave JSP validation on until you have fixed any problems except those caused by these tags; before deploying, select Window > Preferences, select Validation in the tree, and uncheck the JSP Syntax Validator check box.
|
|||
|
Workaround: Refer to the
Tuxedo Control Migration white paper provided in PDF format. The PDF provides migration options from the Tuxedo Control to other alternatives.
|
|||
The first time you run Project > Clean after importing a project, Workshop for WebLogic may not clean all of the files from the .apt_src directory
|
|||
|
When generating Xbean types for a Service Control, there are a limited number of situations where the wrapper type from the WSDL is exposed as a type in the Service Control (e.g. when there are multiple occurrences of the same Document type in the same operation signature). If the generated types jar is visible to the target JWS classloader, a duplicate type error will be thrown during deployment.
|
|||
|
Workshop for WebLogic ships an SVN snapshot of Apache Beehive (post v1.0.1). There are certain APIs that were introduced into Beehive at Apache, post v1.0.1, but have not officially shipped with a release from Apache.
|
|||
|
Processing large (i.e. ~1MB) schema files in Workshop for WebLogic with the XMLBeans Builder can result in unacceptably long build times due to the performance of both the XMLBeans compiler and the Eclipse Java builder.
Workaround: XMLBeans compiler performance: XMLBeans compiler performance can be improved by disabling assertions for the XMLBeans code. Assertions can be disabled by adding the line "-da:org.apache.xmlbeans..." to the file workshop92/workshop4WP/workshop4WP.ini. This change will have the most dramatic effect if the XMLBeans Builder is not used to generate Java and XMLBeans files (e.g. in simple ALSB XQuery Mapper projects).
Java builder performance: The incremental nature of the XMLBeans and Java Builders ensures that subsequent build cycles only process the modified elements of the schema (and generated Java) and should thus complete in a fraction of the original time, however, a clean rebuild of the project will incur the full processing cost. Therefore, if XMLBeans source is required and performance of the incremental XMLBeans builder proves problematic, you may want generate the XMLBeans Jar file once outside of Workshop for WebLogic via the commandline build and then reference the generated Jar in your application.
|
|||
|
During the installation phase of the 9.2.1 upgrade, if the internet connnection is lost, users may see an error that a JAR file was not completely downloaded:
|
|||
|
Generating XML types for a .xsd file returns an error, if the .xsd file refers to another .xsd file through normal relative path (file protocol).
|
|||
|
Buffered operations on a ServiceControl must be void. However the Message Exchange Pattern (MEP) in the underlying WSDL can be either request/response (with an empty response), or oneway (a request with no response).
In the case of a request/response MEP over JMS, the presence of @MessageBuffer will cause the request to deadlock and eventually timeout. The following warning message will generally be produced:
Potential blocking operation {http://someNamespace}someOperation: a synchronous request/response invocation within a transaction using the JMS transport can cause deadlocks. Please refer to WebLogic documentation for details.javax.xml.rpc.soap.SOAPFaultException: Failed to receive message java.io.IOException: Request timed out
Workaround: If you can influence the design of the target JWS, having the JWS operation annotated with @Oneway will direct that the underlying MEP be oneway, and will avoid this situation. If you can not influence the design of the target JWS, then the workaround is to add the TransactionAttribute annotation to the ServiceControl operation:
@MessageBuffer |
|||
|