![]() ![]() ![]() ![]() ![]() ![]() |
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 10.0 uses the Web Tools Platform 1.5.
Version 10.0 supports Apache Beehive, an open source framework for web applications. Support for Apache Beehive includes:
Version 10.0 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 10.0, now built on JSR-181. Web service support includes:
As with version 8.1, version 10.0 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 10.0 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 10.0 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.
|
|||
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/3.2.
|
|||
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.2). There are certain APIs that were introduced into Beehive at Apache, post v1.0.2 but have not officially shipped with a release from Apache.
|
|||
When upgrading some .jcx files, the upgrade process may not be able to copy some MBCS characters into the resulting upgraded file. This happens when a WSDL with UTF-8 encoding is inside a file with some other sort of MBCS encoding, like MS932 (Japanese) and MBCS characters appear in that file outside of the WSDL definition.
|
|||
When a web service or other artifact is in a web project that is part of more than one EAR, the Run on Server can produce the wrong URL.
|
|||
Invocation of buffered Control methods will fail at runtime if deployed (via the IDE) to a server with more than one JMS Server
The IDE will auto-deploy required Workshop libraries when deploying an application. The use of @MessageBuffer on Control methods creates a dependency on application-scoped JMS resources in the weblogic-controls library. If the weblogic-controls library is deployed (by the IDE) to a server with more than one JMS server, the library will deploy, but the application-scoped JMS resources will not be available. This is because the IDE depends on default sub-module targeting, and default sub-module targeting relies on the target containing exactly one JMS Server. A message similar to the following warns that there is an issue with the deployment:
<The JMS module named "WlwRuntimeAppScopedJMS" inside
Note that even though there is a warning message, the library is deployed to the server. This means that applications that are dependent on the library will also successfully deploy. However, invocation of buffered Control methods will fail at runtime with a message similar to the following:
"Failed to invoke end componentFailed to invoke methodMessage |
|||
If your application enables message buffering on controls using the annotation com.bea.control.annotations.MessageBuffer, you may have the following error when you try to deploy it on a cluster:"While attempting to create destination MSG_BUFFER_QUEUE in module <name_of_your_ear>!WlwRuntimeAppScopedJMS the JMSServer of name <name_of_your_cluster> could not be found".
Workaround: In this case, you must target the MSG_BUFFER_QUEUE to a specific JMS Server with the following submoduletargets option to your weblogic.Deployer command:
-submoduletargets cgJMSServer@WlwRuntimeAppScopedJMS@WseeJmsServer_auto_1 |
|||
Migration of a Workshop for WebLogic 9.2 application that has the XDoclet facet enabled to version 10.0 results in the following error message.
"The preferences for the xdoclet runtime does not point to a valid installation" |
|||
The Perforce Eclipse plugin (P4WSAD) does not add new .prefs files after upgrading an application from version 9.2 to version 10.0
Description: When you upgrade a Workshop for WebLogic version 9.2 application to version 10.0 the Perforce Pending Changelists view does not show all of the files created in the upgrade process. For example, the com.bea.workshop.wls.core.prefs which replaces the com.bea.wlw.libmodules.core.prefs file is not added to the view.
|
|||
"exact-match" element value in weblogic.xml and weblogic-application.xml files are ignored during project migration
|
|||
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 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 |
|||
When upgrading web applications to version 10.0, the Page Flow Controllers source folder may revert to the default location in some cases
Certain 9.2 web projects with the Beehive NetUI facet may not retain the value of the Associated Files Model settings. Specifically, if such a project has more than one source folder, and the Page Flow Controllers property panel has been set to a source folder other than the default, this value will revert to the default when the project is upgraded to 10.0.
|
|||
Leaving the "upgrade projects" wizard open for a long time before canceling or finishing can leave the Workshop IDE in a bad state.
|
|||
Description: An issue may surface when a 9.2 Beehive application is deployed on WebLogic Server 10.0. The symptom with this scenario is a java.lang.IllegalStateException being thrown. The underlying issue is with the javax.servlet.ServletException which changed from Servlet 2.4 to Servlet 2.5.
Workaround: Upgrade the application to use Beehive 10.0 libraries (which work with either Servlet 2.4 or Servlet 2.5). If the 9.2 application cannot be compiled in 10.0, then manually updating the deployment descriptors in the 9.2 application EAR to use the 10.0 Beehive libraries will resolve this issue. For example:
|
|||
Description: The Workshop for WebLogic Platform version 10.0 documentation gives an incorrect command for starting help in stand alone more.
Workaround: Run the following command to start help in standalone mode.
%BEA_HOME%/jdk150_06/bin/java -classpath %BEA_HOME%/tools/eclipse32/eclipse/plugins/org.eclipse.help.base_3.2.1.R321_v20060822.jar org.eclipse.help.standalone.Infocenter -command start -eclipsehome %BEA_HOME%/tools/eclipse32/eclipse -port 7034 -noexec -product com.bea.workshop.product.wl.workshop |
|||
User's who upgrade an 8.x application to a 9.x/10.x application may experience issues when making multiple method calls to a JDBC control from a single page flow method
http://download.oracle.com/docs/cd/E13226_01/workshop/docs92/ws_platform/upgrading/conChangesDuringUpgrade.html
User's who upgrade an 8.x application to a 9.x/10.x application may experience issues when making multiple method calls to a JDBC control from a single page flow method. The crux of the issue is that when the first call is made to the JDBC control a new transaction is created by our transaction interceptor. When that call returns the transaction is either committed or rolled back.
On the next call to the JDBC control a new transaction is created, but the JDBC connection being used by the control cannot be used in another transaction (it has been associated as a resource of the first transaction).
The behavior in 8.x page flows was for the JDBC control to release its JDBC connection after each method invocation. The transaction scope for a control method being invoked from a page flow was to start a transaction at the beginning of the control method invocation, and end the transaction on the return of the method. If the control rolled back the transaction, all operations performed within that transaction would be rolled back as well.
|
|||
Project references that are part of a web app but not part of an ear may result in NoClassDefFound errors
If a web project in an ear references a java project via the J2EE Modules Dependencies -> Web Libaries settings *and* if the java project is not part of the ear, then the classes are not loaded and you see NoClassDefFound errors. This only occurs during iterative development. Export ear will correctly copy the jar to the web-inf/lib directory of the web app in the ear.
|
|||
The Web Service stack in WebLogic Server 9.x/10.0 does not support nested types as parameters and/or return values. However, Beehive Controls often use inner classes as the pattern for data values (e.g., The JDBC Control contains a commented out example of an inner class to hold the return values from the database queries). Therefore the use of Beehive Control nested values in a JWS is not supported
|
|||
When mutiple web service controls, with callbacks, have identical class names (ignoring package name) an error will occur in jwsc. This error will appear in the publish step in the ide, during the asseble step in exported ant scripts, or when exporting an ear file from the ide. In previous versions of Workshop the exported ant scripts would incorrectly report that the assemble step had succeeded even though this conditon was present. This was becuase the ant script did not attempt to run jwsc on gernerated java files.
|
|||
Service control generation based on WSDL callbacks named with underscores and numbers can result in incorrect callback method names. This will occur if a lower case letter follows an underscore or number.
a_b a_B javax.xml.rpc.JAXRPCException: SOAPFaultException - FaultCode |
|||
Auto deployment of new library modules to a 10.0 domain could lead to a class not found during production deployment
In Workshop 10.1, when a user creates a new target runtime which points to a Workshop for WebLogic 10.0 installation, and develops an application against a domain from that installation, Workshop 10.1 will automatically publish newer versions of library jars for all facets in the application, if newer versions exist.
|
|||
In moving from a Workshop for WebLogic 10.0 or earlier domain to Workshop version 10.1, you should initiate domain upgrade by using the IDE. This will make the updates to the domain so that you will have the latest runtime binariers for Workshop version 10.1.
If you are managing the domain of an environment that doesn't have the IDE available (for example a platform in which the IDE is not supported or a deployed server) manual upgrade may be required.
beehive-controls-1.0.2.1.ear
The following topics will help you deploy the libraries. using weblogic deployer and weblogic console.
|
|||
A runtime exception occurs while invoking a 10.0 application with a service control on WebLogic Server 10.0 MP1
A ServiceClassCacheException occurs when a 10.0 application with a service control is invoked after deploying the application on WebLogic Server 10.0 MP1. This exception occurs due to a mismatch in the serial version UIDs for the javax.xml.namespace.QName class in JDKs 150_06 and 150_11.
|
|||
Workshop returns an error when editing Installed Runtimes after performing an application upgrade from 9.2 MP2 to 10.0.
|
|||
![]() ![]() ![]() |