Release Notes Addendum
last updated: March 2008
This is an addendum to the release notes provided within the product. As new issues arise, they will be added to this addendum.
The Profiler and Code Coach can't be invoked from JDeveloper when JDeveloper is installed from the 10.1.2.3 Developer Suite patch set. This is because
both of these are OJVM specific and in this version of JDeveloper, OJVM isn't available as OJVM is not being installed.
The work around is to run the installOJVM.bat from the
The default HTTP port number for the Enterprise Manager instance of AS 10.1.2.0.2 is 18100 for Windows and 1156 for Unix.
When you migrate a JNLP application created in JDeveloper 9.0.2 to JDeveloper 10.1.2 and run it you will get a permission denied error. To fix this open local.jsp, localmt.jsp (or oc4j.jsp, oc4jmt.jsp) in a text editor, and add the following line after the closing information tag:
Users will see a harmless error message
checkIsLocalHost() error: during the deployment of applications using IDE. This message can be ignored and does not have any effect on the overall deployment process.
If you have jdk1.5\jre\bin on your path when you start JDeveloper on Windows, you will not be able to use the debugger with JDK1. (The default JDK with JDeveloper 10.1.2) with the HotSpot JVMs (hotspot, client, or server). Attempting to debug with JDK1.4 with a HotSpot JVM will cause the following error to appear in the log window:
FATAL ERROR in native method: No transports initialized Transport dt_socket failed to initialize, rc = 509.
The error is caused by the debuggee process looking for the dt_socket.dll and finding the JDK1.5 version of the dll from the jdk1.5\jre\bin directory on the path instead of the JDK1.4 version of the DLL The error will not occur when using the debugger with OJVM because OJVM does not use the dt_socket.dll.
Try either of these workarounds to avoid this problem:
If you created your own library definition in JDeveloper 10.1.2.0.0 and added the EL jar files (commons-el.jar, jsp-el-api.jar, and oracle-el.jar) to your library manually you may see
NoClassDefFound errors when you compile or run in JDeveloper 10.1.2.1.0. You can fix the library definition by pointing the jar files that are present in the new location from
When you customize the basic ADF Data Action, their custom action class should directly or indirectly extend the DataAction class in the oracle.adf.controller.struts.actions package. On the other hand, when you customize an action for an ADF Data Page it should directly or indirectly extend the DataForwardAction class in that same package. Additionally for data pages, JDeveloper associates the action to its related page by recording the name of the page in the value of the parameter attribute of the Struts action in your struts-config.xml file. In contrast, plain data actions which are not data pages do not have a parameter attribute recorded.
In 126.96.36.199 and 10.1.2 it is possible for users to accidentally create a custom data action class which incorrectly extends the DataForwardAction class instead of the correct DataAction class. This was harmless in 188.8.131.52, but in 10.1.2 a data action whose custom action class extends DataForwardAction instead of just DataAction has an undesirable side-effect when the Struts page flow diagram is opened the first time in each JDeveloper session. JDeveloper 10.1.2 notices that the action extends DataForwardAction and assumes that you meant it to be a data page. It then notices this presumed data page is missing its required parameter attribute, so JDeveloper 10.1.2 adds a parameter="unknown" attribute for it. This can have the unwanted side effect of making your data action nodes in the diagram turn into data page nodes.
The way to avoid the problem is to insure that your custom data action classes that are not intended to be data pages:
When creating a read-only view object by selecting the Read-only Access radio group on the first panel of the JDeveloper 10.1.2 view object wizard, after entering your SQL query on the following panel, if you continue to (Next>) through the wizard and end up visiting the "Attributes" panel, the first attribute will inadvertently have its "Selected in Query" property set to false. This changes the SQL-derived attribute populated by your query's first SELECT list column into a transient attribute unintentionally. The two easy workarounds are:
Prior to 10.1.2, ADF BC runtime was incorrectly hard-coding an assumption that the return type of a view link accessor exposed at entity level was a RowIterator. This caused problems when the viewlink exposed thusly was a 1-to-1 link. Our engineers fixed that bug (#3839762) in 10.1.2, but it uncovered a new issue discovered after 10.1.2 build 1811 shipped. The issue is a design time bug that incorrectly reverses the source and the destination types of the view link when it writes the view link accessor type in your entity's XML descriptor. Prior to 10.1.2, when we were hard-coding the expectation of a RowIterator, the fact that the wrong type was in the XML didn't matter since we didn't consult the type at runtime. Now that we are using the XML-based <ViewLinkAccessor> row type info in 10.1.2, the fact that it's incorrect surfaced this new ClassCastException.
If you expose a
WorksInDeptLink view link between
EmpView on the Dept EO level with an accessor name of
Employees, you will currently end up with the incorrect XML snippet in your
Dept.xml file like this:
<!-- In Dept.xml entity XML file -->
DeptView VO is exposing a custom Row class, it will reflect that instead and look like:
<!-- In Dept.xml entity XML file -->
Trouble is, neither the generic
oracle.jbo.Row nor the more specific
test.mypackage.DeptViewRowImpl is correct for the return type of this accessor. The workaround until we fix this issue in a maintenance release is to update the
Dept.xml file outside of JDeveloper to reflect the correct type of the view link accessor. In the example above, you would change the type to be
oracle.jbo.RowIterator like this:
And this fixes the problem.
NOTE: If you "touch" the view link in the view link editor again, you may have to reapply this workaround after the wizard re-writes the wrong type value again.
In the case of web applications, each top-level application module uses a session cookie to increase application stability (using failover) and help manage state. ADF also adds a cookie of its own. A limitation in Microsoft Internet Explorer prevents it from accepting more than 20 cookies per unique host. Therefore, if your application may be accessed through Microsoft Internet Explorer, and you have not disabled failover, you should not use more than 19 top-level application module instances per client instance. Any additional application module instances you need should be nested in the definition for one of the 19. Using more than 19 top-level application module instances in a single client instance may cause unpredictable behavior with Microsoft Internet Explorer.
When you have a web service running in OC4J, and run a generated stub against it, the stub will fail with a 'No deserializer found' message when the target namespace for the service has an underscore in the first part of the URL. This is because when the stub is run, the underscore in the target namespace is changed to a hyphen, for example, http://hr_conn/My_WebService1.wsdl becomes http://hr-conn/My_WebService1.wsdl .
The workaround is to either:
When selecting "View Report" on the context menu for any Web Service on UDDI registry the information page about the selected Web Service is shown with all multibyte characters garbled on JA locale. This is just a view issue and can be avoided by the following workaround:
cd <JDev_Install>/jdev/lib <J2SE_Install>/bin/jar xvf jdev.jar oracle/jdevimpl/webservices/uddi/report/uddiservicerpt.xsl
<xsl:output method="html" /> to <xsl:output method="html" encoding="shift_jis"/> : For Windows, or SJIS environment on Unix <xsl:output method="html" encoding="euc-jp"/> : For EUC environment on UNIX
You may receive a CDR-17043 and SQL error occurred when opening version history against Oracle SCM. Currently there is no workaround available.
If you are using Standalone OC4J to run an application that uses JAAS authentication and Oracle ADF Business Components, and you are not using the copy of jazn.xml provided in <oc4j_home>/home/config, you must pass the location of your copy of jazn.xml to the JVM using the property oracle.security.jazn.config. For example, if your jazn.xml file is in the directory /jazn/, use the command:
java -Doracle.security.jazn.config=/jazn/jazn.xml -jar oc4j.jar
to start the server.
When deploying a JClient WebStart application based on a BC4J Session Bean to Oracle Application Server, you may encounter the following deployment error:
Closing connection to Oc4jDcmServlet #### DCM command did not complete successfully (-8) #### HTTP return code was -8 Exit status of DCM servlet client: -8
To fix this problem, follow the workaround described below:
1. In the web.xml file generated by JClient WebStart Wizard, remove the <ejb-ref> element and its contents completely. A sample entry in web.xml looks like:
<ejb-ref> <ejb-ref-name>ejb/AppModuleBean</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <home>mypackage1.common.ejb.beanmanaged.AppModuleHome</home> <remote>mypackage1.common.ejb.beanmanaged.RemoteAppModule</remote> <ejb-link>AppModuleBean</ejb-link> </ejb-ref>
2. Remove the profile dependencies set in the war deployment profile. To do this:
3. Deploy the war to iAS and run WebStart.
Copyright � 2005, Oracle Corporation. All Rights Reserved.