| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.2) for Solaris Operating System (SPARC 64-Bit) Part Number B32421-05 |
|
|
View PDF |
| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.2) for Solaris Operating System (SPARC 64-Bit) Part Number B32421-05 |
|
|
View PDF |
This chapter describes issues associated with Oracle JDeveloper. It includes the following topics:
For additional information not available at the time of this document's publication. Please review the Oracle JDeveloper (10.1.3.1.0) Release Notes Addendum at http://www.oracle.com/technology/products/jdev/htdocs/10.1.3.1/index.html
For more information and technical resources for JDeveloper, visit the JDeveloper product center on the Oracle Technology Network at http://www.oracle.com/technology/products/jdev/101.
This section describes general IDE issues and workarounds. It includes the following topic:
In some cases binary files can become corrupted when using JDeveloper's internal CVS client against a CVSNT server. The workaround is to use CVSNT's client within JDeveloper. This can be configured on the Versioning | CVS panel of IDE preferences.
This section describes general deployment issues and workarounds. It includes the following topic:
Section 7.3.1, "EJB Web Service Fails to Deploy to JDeveloper's Embedded Server"
Section 7.3.2, "ADF Web Application with Ejb3 Model Project Dependency Fails to Deploy"
Section 7.3.3, "Deploying JDeveloper Deployment Profiles to Archive Files on the File System"
JDeveloper may exceed the length of the path names permitted by Windows when you compile an EJB session bean with a web service annotation. The path name JDeveloper generates for the web service class file is concatenated from three elements: the path to the application-deployment folders (set by system and not editable), the path to the web service source folder (also set by system), and the path to the class file specified by its package name (set by user and must be as short as possible).
For example, the following path would be created for a web service class file, where the user-specified portion of the path name is based on the package name com.oracle.myapp.ejb.webservice.test.
<JDev_Install>jdev\system\oracle.j2ee.10.1.3.37.58\embedded-oc4j \application-deployments\\current-workspace-app \MyApplication_MyProject\ws-src\com\oracle\myapp\ejb\webservice\test
and results in the exception:
oracle.j2ee.ws.common.tools.api.SeiValidationException: Interface <classname>.SessionEJBBeanPortType: The class could not be loaded from the class path.
You can workaround this limitation by shortening the name of the package you enter when you create the EJB session bean. For example, instead of com.oracle.myapp.ejb.webservice.test, as shown in the above example, the package name com.oracle.myapp will result in a legal class path length.
When you deploy an ADF web application WAR file to Standalone OC4J you may encounter the following error due to multiple persistence unit definitions resulting from an EJB3 model project dependency:
DeployerRunnable.run[application1:ejb3_mdnav_adffaces] - Multiple persistence units with name "model" are defined at the same scope.oracle.oc4j.admin.internal.DeployerException: [application1:ejb3_mdnav_adffaces] - Multiple persistence units with name "model" are defined at the same scope.
To avoid this error, update the ViewController project settings to remove the dependency on the Model project before deploying the ADF Web application to Standalone OC4J.
When deploying JDeveloper deployment profiles to an archive file the default behavior is to deploy the archive as standard J2EE. In order to deploy an archive to a file for a specific application server platform to incorporate platform specific descriptor handling, the user must set the Target Connection in the Deployment Profiles - Platform page. The Target Connection can only be set to something other than the default (J2EE) after creating an application server connection in the connection navigator.
This section describes database issues and workarounds. It includes the following topic:
Oracle Lite version 10.2.0.2 does not support standard JDBC metadata for column definitions, resulting in an inability to create EJB entities. Oracle expects this to be fixed in Oracle Lite 10.2.0.3.
This section describes modeling issues and workarounds. It includes the following topic:
From the Application Navigator context menu, the refactoring submenu is visible for navigator packages containing UML artifacts. However, refactoring the package will NOT cause UML artifact to be refactored, though Java and other types will be refactored as expected.
The Java Modeler's popup code editor is not currently accessible when using the JAWS screen reader. The workaround is to invoke Go To Source instead of Edit for Java elements on the diagram, which will invoke the main code editor.
This section describes Toplink issues and their workarounds. It includes the following topics:
When importing database tables named with multibyte characters, you must change the JDeveloper encoding to UTF-8.
Select Tools > Preferences > Environment.
Change Encoding to UTF-8.
Restart JDeveloper, then import the tables.
This section describes EJB issues and their workarounds. It includes the following topics:
In 10.1.3.1 the life span of an entity's Persistence Context is strictly tied to the life span of its associated transaction, since by default, a PersistenceContext's type is PersistenceContextType.TRANSACTION.
This requirement was relaxed in JDeveloper 10.1.3, and some applications were found to be dependent on this requirement not being met.
To operate under the stricter requirement in JDeveloper 10.1.3.1, EJB 3.0 Stateless Session beans migrated from JDeveloper 10.1.3 and interacting with web clients may need to be changed to Stateful Session beans.
In addition to this change, the generated statement:
@Resource EntityManager em;
should be changed to:
@PersistenceContext(type=PersistenceContextType.EXTENDED)EntityManager em;
to allow web clients to perform additional operations on entities returned from the (newly Stateful) Session bean.
EJB 3.0 runtime is different between JDeveloper 10.1.3 and JDeveloper 10.1.3.1. An EJB 3.0 application that was created in JDeveloper 10.1.3 will only work with Oracle Application Server 10.1.3, and an EJB 3.0 application created in JDeveloper 10.1.3.1 will only work with Oracle Application Server (SOA) 10.1.3.1.
You can migrate EJB 3.0 applications from JDeveloper 10.1.3 to JDeveloper 10.1.3.1 by following the instructions in the online help topic Migrating EJB 3.0 Applications from Oracle JDeveloper 10g Release 10.1.3 to 10.1.3.1 by selecting Getting Started with Oracle JDeveloper > Migrating to Oracle JDeveloper 10g.
This section describes Web Services issues and their workarounds. It includes the following topics:
Section 7.8.1, "Top-Down SOAP 1.2 Services Changed to SOAP 1.1 after Editing"
Section 7.8.2, "Top-Down Service with One-Way Operations Changed to Two-Way Methods after Editing"
Section 7.8.3, "Top-down Web Services Generated with Enumerated Types Fail Validation"
Section 7.8.4, "Deleting InitParam or Header in a Web Service Handler Causes an Error"
Section 7.8.5, "Web Service Proxy Fails when Running with Reliability Settings"
Section 7.8.7, "Invalid Web Service Endpoint in Generated Proxy for Multi-Port WSDLs"
Section 7.8.8, "Runtime Exception when More than One Web Service Exists in a Project"
If you create a web service top-down from a WSDL that contains SOAP 1.2 bindings, then modify that service in the web service editor, the bindings are changed to SOAP 1.1.
The workaround is in the Web Services Editor dialog, manually deselect SOAP 1.1 Binding and select SOAP 1.2 Binding instead.
If you create a top-down web service that has one-way operations, then use the Web Service Editor to change the service or invoke Regenerate Web Service from Source, the one-way operations are changed to two-way operations.
The workaround is in the Web Services Editor dialog, manually select the Create One-Way Operations From Void Methods checkbox.
When you generate a top-down web service a WSDL with enumerated types, subsequent changes made to the service in the Web Service Editor cannot be committed due to an error in validation.
If you have created a web service handler that uses an InitParam and/or a Header, and you subsequently edit the handler to remove the InitParam or the Header, JDeveloper displays an error message.
The workaround is to remove the handler, then recreate it without the initial parameter.
When you run a proxy to a web service that has reliability enabled, you may find that it fails, and on examination with the HTTP Analyzer the SOAP message returned from the server has an empty body. This can occur because the default value of Expiry Time on the Operation Settings tab of the Proxy Reliability wizard.
The workaround is to increase the expiry time to 2 seconds or more.
If you deploy an EJB3.0 web service to external OC4J, and try to test it from Oracle Enterprise Manager, the Invoke button is not always present.
There is no workaround.
When you create a proxy to a web service with more than one port, the proxy may be generated with an invalid endpoint for the web service.
The workaround is to examine the WSDL to find the correct endpoint URL, and paste this into the generated proxy class.
If you create two or more web services in a project that use the same mapping file, you will get a runtime exception.
The workaround is:
For bottom-up web service generation, specify a serviceName argument value that does not already exist for the second web service.
For top-down web service generation, make sure the web services are each in a different WAR for deployment so that the same deployment descriptor is not used.
This section describes JavaServer Faces issues and workarounds. It includes the following topic:
JDeveloper 10.1.3.1 upgrades to the JavaServer Faces reference implementation version 1.1_02. This maintenance release of the JSF runtime from Sun introduces a new restriction preventing the processing of any JSF page located in the ./WEB-INF directory (or subdirectory thereof). If your JSF applications contain pages in the WEB-INF directory, you will need to move those pages to another directory under the web root other than WEB-INF for them to function correctly. If your JSF pages use ADF Model data binding, after moving the JSP/JSPX pages from ./WEB-INF (or subdirectory) to a new directory under your web root, you will need to reflect the change in the "path" value inside the <pageMap> section of your DataBindings.cpx file. For example, if your page previously had a "path" value of /WEB-INF/page/Test.jspx and you moved this Test.jspx page to ./public_html/page/Test.jspx, where ./public_html is the HTML root directory of your view controller project -- then you must edit the value of the path and change it from /WEB-INF/page/Test.jspx to /page/Test.jspx.
This section describes documentation errata. It includes the following topic:
The JAZNMigrationTool provides a way to migrate the contents of one store to another that can then be loaded to the LDAP directory. The command to be used is:
java JAZNMigrationTool -D binddn -w passwd [-h ldaphost] [-p ldapport] [-sf filename] [-df LDIF_filename] [-sr source_realm] [-dr dest_realm] [-m policy|realm|all] [-help]
Below is an example of migrating all users, roles, and JAAS policies from embedded-oc4j\config\system-jazn-data.xml to j2ee\home\config\system-jazn-data.xml
set CLASSPATH=JDEV_HOME\j2ee\home\jazn.jar;%CLASSPATH%JDEV_HOME\jdk\bin\Java oracle.security.jazn.tools.JAZNMigrationTool -w welcome -sf JDEV_HOME\jdev\system\oracle.j2ee.xxxx\embedded-oc4j\config\system-jazn-data.xml -df JDEV_HOME\j2ee\home\config\system-jazn-data.xml -dt xml
Note that JDEV_HOME should be the directory where they install JDeveloper. XXXX represents the final build number.
For more information issue Java JAZNMigrationTool -help.
When running the ADF installer within JDeveloper (Tools | ADF Installer) against an Oracle Application Server 10.1.2 instance, you may encounter the error Cannot finish the installation even if the server is shut down. In addition to stopping the Application Server instance, you must also shut down the Application Server Control Manager (Enterprise Manager) service before running the ADF Installer against the Oracle Application Server 10.1.2 instance.
Use of the restore facility does not redeploy bc4j.ear to the Oracle Application Server 10.1.3.0.0. This should not affect functionality, as datatags.ear is the same as bc4j.ear. However, if required, bc4j.ear must be manually deployed using the Enterprise Manager console.
|
 Copyright © 2008, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
