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.
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:
Remove jdk1.5\jre\bin from the path before starting JDeveloper.
Use OJVM when debugging. This is specified in the Project Properties dialog
box, on the Runner panel.
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:
Extend DataAction instead of DataForwardAction
Do not have a parameter attribute in their corresponding
struts-config.xml<action> element entry.
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:
Click the (Finish) button in the view object wizard before (Next>)-ing
through to the "Attributes" page of the wizard, or
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:
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:
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
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
Open <JDev_Install>jdev/bin/jdev.conf and add the following code:
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:
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:
Bookmark
