There is one fundamental change in ADF BC from 11g R2. It's not recommended anymore to use oracle.jbo.domain.Number type for numeric data types. As per ADF developer guide for 11g R2 - New Fusion web applications should use the default Java Extended for Oracle type. Java Extended For Oracle as Data Type Map is suggested by default, when you want to generate ADF BC, Oracle Domains type is still supported though:
With Java Extend For Oracle we don't have anymore one single type for numbers, but java.math.BigDecimal, java.math.BigInteger, etc. Somehow, I will miss good oracle.jbo.domain.Number, just think how complicated will be now refactoring - if we need to synchronize and change ADF BC based on customer request, we would need to care now about proper type usage. But anyhow, we should follow best practices and use Java Extended For Oracle type with new ADF applications.
I saw on the OTN Forum today, one issue was reported related to java.math.BigInteger type and ADF BC - Bug: JBO-25029: Domain class BigInteger is not found. JDeveloper11.1.2.0.0. I wanted to reproduce it with test case - created NUMBER(20) type column (BIG_INTEGER) in database:
EO is generated with all three numeric types - java.math.BigDecimal, java.math.BigInteger and java.lang.Integer - not too happy with this (imagine if database column precision will be changed, we would need to change type accordingly inside managed bean method and ADF BC implementation classes for certain attribute). Imagine into what horror we could end up, if we would need to refactor this EO (and 100 others), and change numeric types:
Run application, without doing any change for auto-generated code and you get error reported on OTN forum - domain class BigInteger is not found:
This error happens, because EO attribute of java.math.BigInteger type is not correctly auto-generated by ADF BC - type is not specified correctly:
Change BigInteger into java.math.BigInteger:
It works well:
Download sample application - ADFBCTypes.zip.
Update from Duncan Mills, posted on ADF EMG related to this blog:
In the limited use case that you explain here where the data model is changeable then you probably want to stick with the JBO Number domain. However, this is a corner case and not representative of most systems so the recommendation to use the new default stands. Saying that, we'll not be dropping the old typemap. It will be there forever, there is just way too much code that uses it, so there is no problem with continuing to use it.
With Java Extend For Oracle we don't have anymore one single type for numbers, but java.math.BigDecimal, java.math.BigInteger, etc. Somehow, I will miss good oracle.jbo.domain.Number, just think how complicated will be now refactoring - if we need to synchronize and change ADF BC based on customer request, we would need to care now about proper type usage. But anyhow, we should follow best practices and use Java Extended For Oracle type with new ADF applications.
I saw on the OTN Forum today, one issue was reported related to java.math.BigInteger type and ADF BC - Bug: JBO-25029: Domain class BigInteger is not found. JDeveloper11.1.2.0.0. I wanted to reproduce it with test case - created NUMBER(20) type column (BIG_INTEGER) in database:
EO is generated with all three numeric types - java.math.BigDecimal, java.math.BigInteger and java.lang.Integer - not too happy with this (imagine if database column precision will be changed, we would need to change type accordingly inside managed bean method and ADF BC implementation classes for certain attribute). Imagine into what horror we could end up, if we would need to refactor this EO (and 100 others), and change numeric types:
Run application, without doing any change for auto-generated code and you get error reported on OTN forum - domain class BigInteger is not found:
This error happens, because EO attribute of java.math.BigInteger type is not correctly auto-generated by ADF BC - type is not specified correctly:
Change BigInteger into java.math.BigInteger:
It works well:
Download sample application - ADFBCTypes.zip.
Update from Duncan Mills, posted on ADF EMG related to this blog:
In the limited use case that you explain here where the data model is changeable then you probably want to stick with the JBO Number domain. However, this is a corner case and not representative of most systems so the recommendation to use the new default stands. Saying that, we'll not be dropping the old typemap. It will be there forever, there is just way too much code that uses it, so there is no problem with continuing to use it.
Thanks for your great information.
ReplyDeleteHi Andrejus ! , I Have the same problem, but in this ocasion, JDeveloper automic configured the Model proyect to :
ReplyDeleteData Type Map : Java Extended for Oracle
that opcion I cannot edit, because JDeveloper don't follow me, That's right !!
But I have a Data Base Table with a Fiel called :
Code NUMBER( 38, 0 ),
Salary NUMBER( 20, 2 )
When I export this table to JDeveloper as Entity Objects, JDeveloper Automatic configure the Entity's source as :
I created my View Objects and Links, and my Application Module, but, when I test this AM, the tester still show me the Error (JBO-25029) , as you show at image 4.
What can I do , to resolve that Bug ????
if I am supposedly using Java Extension Classes.
This issue is posted in :
Do you change it manually for fix as on image 5 and 6?
ReplyDeleteAndrejus
No, because JDeveloper automatic put the Fields in the Entity Object as :
ReplyDeleteCode Type = java.lang.Integer
Salary Type = java.math.BigDecimal
As you see, I never Using a BigDecimal Type in anywhere, really I don't know the why continue show me the error ( image 6 ).
I am doing my project for my university, and I'm several days late because of this bug.
You need to open EO code, and fix it by yourself. See image 5 and 6 :)
ReplyDeleteAndrejus
Thanks Andrejus, but I created a new Fusion Application, and it run correclty.
ReplyDeleteNow, I have a last question .
Do I need change the oracle.jbo.domain.Number to java.lang.Integer or to java.math.BigDecimal , the return type of a EntityImpl function , it in this case :
/**
* I access to this method in groovy as : adf.object.getSequenceValue( "Employees_seq" )
*/
public oracle.jbo.domain.Number getSequenceValue( String nombreSeq ){
SequenceImpl seq = new SequenceImpl( nombreSeq, this.getDBTransaction() );
return seq.getSequenceNumber();
}
What do you says or think about it ?
I prefer to use oracle.jbo.domain.Number type, especially in your example. Use Java types, if you generate Web Service.
ReplyDeleteAndrejus
Ok, I will use java types . Thanks Andrejus ;)
ReplyDeleteHi,
ReplyDeleteI have a problem. i have implemented one dynamic table based on a dynamic vo.
it is working fine for the first time but second time i m getting error. I think its a rendering issue. can u please elaborate how to handle this kind of errors.
target unreachable .'department_name' returned null.