Oracle JDeveloper 10g

Release Notes Addendum

Version 10.1.2

last updated: March 2008

Content

Introduction

This is an addendum to the release notes provided within the product. As new issues arise, they will be added to this addendum.

Workaround Necessary to Install OJVM When Installing JDeveloper Through Developer Suite (6870514)

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
<DS_Installation>\jdev\bin directory

Incorrect Ports for Application Server 10.1.2.0.2 Connection (4634928)

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.

Issue Migrating JDeveloper 9.0.2 JNLP Client Applications to JDeveloper 10.1.2 (4416809)

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:

<security><all-permissions/></security>

Error Message When Deploying Applications Using the IDE (4502734)

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.

Unable to Debug with Client VM when JDeveloper Started with JDK 1.5\JRE\BIN in Path (4502080)

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:

Issue When Upgrading Library Definition from JDeveloper 10.1.2.0.0 to 10.1.2.1.0 (4148838)

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 $OH/jakarta-commos-el/ to $OH/jlib/.

Data Actions Extending DataForwardAction Change to Data Pages Incorrectly (4113412)

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 9.0.5.2 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 9.0.5.2, 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:

First Calculated Attr of Read-Only View Object Reverts To Transient  (4081647)

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:

  1. Click the (Finish) button in the view object wizard before (Next>)-ing through to the "Attributes" page of the wizard, or
  2. Mark the "Selected in Query" property for the first attribute back to true.

ClassCastException Accessing One-To-Many Entity View Link Accessor  (4113607)

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 DeptView and 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 -->
   :
  <ViewLinkAccessor
      Name="Employees"
      ViewLink="test.mypackage.WorksInDeptLink"
      ViewLinkEnd="test.mypackage.WorksInDeptLink.EmpView"
      ViewLinkOtherEnd="test.mypackage.WorksInDeptLink.DeptView1"
      Type="oracle.jbo.Row"
      IsUpdateable="false" >
   </ViewLinkAccessor>

If your DeptView VO is exposing a custom Row class, it will reflect that instead and look like:

<!-- In Dept.xml entity XML file -->
   :
   <ViewLinkAccessor
      Name="Employees"
      ViewLink="test.mypackage.WorksInDeptLink"
      ViewLinkEnd="test.mypackage.WorksInDeptLink.EmpView"
      ViewLinkOtherEnd="test.mypackage.WorksInDeptLink.DeptView1"
      Type="test.mypackage.DeptViewRowImpl"
      IsUpdateable="false" >
   </ViewLinkAccessor>

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:

<ViewLinkAccessor
      Name="Employees"
      ViewLink="test.mypackage.WorksInDeptLink"
      ViewLinkEnd="test.mypackage.WorksInDeptLink.EmpView"
      ViewLinkOtherEnd="test.mypackage.WorksInDeptLink.DeptView1"
      Type="oracle.jbo.RowIterator"
      IsUpdateable="false" >
   </ViewLinkAccessor>

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.

Do Not Use Over 19 Top-Level Application Module Instances in One Application

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.

Using Underscores in Namespace Paths can Cause Runtime Errors for Web Services (3992526 )

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:

  • Hand edit the generated stub to replace the underscore with a hyphen. Find the line that starts "m_smr.mapTypes(..." which contains the target namespace, and change the underscore in the namespace with a hyphen.
  • After generating the web service, but before deploying it, hand edit the WSDL document to replace the underscore in the target namespace with a hyphen. Next, deploy the service. Finally, generate the stub directly from the WSDL document (under the WEB-INF.wsdl node in the navigator) rather than from the web service itself.

Report for Web Service on UDDI Registry is Garbled (4070841)

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:

  1. Extract the file used for formatting report with the following command: 
      
cd <JDev_Install>/jdev/lib
<J2SE_Install>/bin/jar xvf jdev.jar oracle/jdevimpl/webservices/uddi/report/uddiservicerpt.xsl
  2. Open the extracted file in the text editor and change the following code: 
    <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
  3. Open <JDev_Install>jdev/bin/jdev.conf and add the following code: 
    AddVMOption -Duddi.serviceReport.Stylesheet=<JDev_Install>/jdev/lib/oracle/jdevimpl/webservices/uddi/report/uddiservicerpt.xsl

Version History Against Oracle SCM (3998099)

You may receive a CDR-17043 and SQL error occurred when opening version history against Oracle SCM. Currently there is no workaround available.

Using Standalone OC4J with External jazn.xml

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.

Unable To Deploy JClient JNLP Application Based On BC4J EJB to Oracle Application Server (4025025)

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.

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065, USA
http://www.oracle.com

Worldwide Inquiries:
1-800-ORACLE1
Fax 650.506.7200

Copyright � 2005, Oracle Corporation. All Rights Reserved.