Hi Brian,
For the wrong exception problems, we have some concerns about the spec
itself. Ideally, the spec should say that the kind of exception being
thrown is the most natural one that will happen in an implementation, or
it should not specify the exact kind of runtime exception at all. What we
don't want to do is add performance overhead in core methods (like
DataObject.get) to catch implementation exceptions, just so that we can
rethrow them as some specific SDO required exception (like
IllegalArgumentException, for example). That said, I think it still makes
sense to open JIRAs to identify the differences between what the spec
currently says, and what Tuscany is doing. Then we can figure out whether
we end up fixing Tuscany, the spec, or both.
Coincidentally, we have very recently fixed some bugs with the Data data
type, so some or all of the problems you noticed may be fixed in the
latest code. If not, please go ahead and open JIRAs for the problem(s) you
still see.
I'm not sure why the various date and time types can't be converted. My
guess is because they're really all just modeled as java.lang.String (of
some specific format) - i.e., there's no DataObject.get/setDay() method
for example, which is where the conversion would happen. The exception is
Type Date, which is modeled as java.util.Date. So to convert form one of
the String date types, you can always go from original type -> Date ->
desired type. Note that in SDO 2.1, there will probably be some new
conversion methods in DataHelper for this.
Thanks,
Frank.
Brian Murray <[EMAIL PROTECTED]> wrote on 07/25/2006 06:07:51 PM:
>
> I believe the following are new JIRA issues, and I plan to open them
> accordingly. Please let me know if I've misunderstood something.
>
> NullPointerException when expecting IllegalArgumentException
> On page 27 of V2.01 of the spec, it is stated that both
> <DataObject>.get(-1) and
<DataObject>.get(getInstanceProperties().size()
> + 1) should result in an IllegalArgumentException. However, each
> results in a NullPointerException.
>
> Type conversion between Date and String does not work.
> On page 146 of V2.01 of the spec, it is stated that conversion from
> String to Date is supported, as well as conversion from Date to
String.
> However, getString on Date type results in IllegalArgumentException,
and
> getDate on String type results in null value. Here is a code
segment:
>
> public void testShowErrorsInSimpleFormat() throws Exception
> {
> DataObject test_obj =
> DataFactory.INSTANCE.create(API_TEST_TYPE);
> Date current_date = new Date(System.currentTimeMillis());
>
> // getString does not work on Date type
>
> test_obj.setDate("dateVal", current_date);
> String returned_string = test_obj.getString("dateVal"); //
> Gives IllegalArgumentException
>
> // getDate does not work on String type
>
> test_obj.setString("stringVal", current_date.toString());
> System.out.println("stringVal = " +
> test_obj.getString("stringVal")); // stringVal = Tue Jul 25 17:24:33
> EDT 2006
> Date test_date = test_obj.getDate("stringVal");
> System.out.println("test_date = " + test_date); // test_date
=
> null
> }
>
> And here is the XSD:
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:sdo="commonj.sdo"
> xmlns:simple="http://www.example.com/api_test";
> targetNamespace="http://www.example.com/api_test";>
> <xsd:import namespace="commonj.sdo"
schemaLocation="sdoModel.xsd"/>
> <xsd:element name="apiTestElem" type="simple:APITest"/>
>
> <xsd:complexType mixed="true" name="APITest">
>
> <xsd:sequence>
> <xsd:element name="stringVal" type="sdo:String"/>
> <xsd:element name="booleanVal" type="sdo:Boolean"/>
> <xsd:element name="booleanVal2" type="sdo:Boolean"/>
> <xsd:element name="byteVal" type="sdo:Byte"/>
> <xsd:element name="stringVal2" type="sdo:String"/>
> <xsd:element name="decimalVal" type="sdo:Decimal"/>
> <xsd:element name="decimalVal2" type="sdo:Decimal"/>
> <xsd:element name="intVal" type="sdo:Int"/>
> <xsd:element name="floatVal" type="sdo:Float"/>
> <xsd:element name="doubleVal" type="sdo:Double"/>
> <xsd:element name="dateVal" type="sdo:Date"/>
> <xsd:element name="shortVal" type="sdo:Short"/>
> <xsd:element name="longVal" type="sdo:Long"/>
> <xsd:element maxOccurs="unbounded" minOccurs="0"
> name="children" type="simple:APITest"/>
> <xsd:element name="bytesVal" type="sdo:Bytes"/>
> <xsd:element name="integerVal" type="sdo:Integer"/>
> <xsd:element name="charVal" type="sdo:Character"/>
> </xsd:sequence>
> </xsd:complexType>
>
> Get IllegalArgumentException when expecting ClassCastException.
> In V2.01 (dated November 2005) of the SDO specification it is stated
in
> the table on page 28 that a ClassCastException is expected when get
> cannot convert from a value to the requested type. However, in many
> instances an IllegalArgumentException is instead thrown.
>
> Here is the example explicitly mentioned in the table as throwing a
> ClassCastException (getDate on a float value), however an
> IllegalArgumentException is seen in the test case.
>
> // IllegalArgumentException when expecting ClassCastException
>
> test_obj.setFloat("floatVal", Float.MAX_VALUE);
> test_obj.getDate("floatVal");
>
> DataHelper field preservation.
> If I use DataHelper to convert from a Date to a Day, and then from
that
> Day to a new Date (will call this one Date2), I would expect that the
> Day value would remain constant. So if we again do Date2 to Day2, I
> would expect Day to be equal to Day2.
>
> // The output of each println (from a single run) is placed in
comments
> beside it
> public void testShowErrorsInSimpleFashion() throws Exception
> {
> Date temp = new Date(System.currentTimeMillis());
>
> // In following sequence - would expect the Day value (here, 21)
to
> be maintained.
> System.out.println("temp = " + temp); // temp = Fri Jul 21
03:51:01
> EDT 2006
> String day = data_helper.toDay(temp);
> System.out.println("day = " + day); // day = ---21 EDT
> Date date2 = data_helper.toDate(day);
> System.out.println("date2 = " + date2); // date2 = Thu Feb 29
> 23:00:00 EST 1968
> String day2 = data_helper.toDay(date2);
> System.out.println("day2 = " + day2); // day2 = ---29 EST
> // No loss of date in conversion to DateTime - why is the
conversion
> to (say) Day or Month not supported?
> }
>
> When I look in DataHelperImpl.java, I see a series of Date Patterns.
It
> seems that Day is being matched to an earlier pattern than the
expected
> one (the expected one is "---dd zz"). When I move that pattern to
first
> in the list, the outcome is affected. Were it not matching an
earlier
> pattern, I would think that moving the correct one to the front of
the
> list would not have an effect.
>
> Leaving DataHelperImpl.java unaltered, Day = 21 EDT, and Day2 = 29
EST
> (in the case above). However, if I put the appropriate pattern first
in
> the list, Day2 is instead = 20 EST. Interestingly, it is still not
the
> correct day (21). However, changing the order (and not deleting the
> others) has changed the results. This indicates to me that toDay had
> been matching one of the earlier patterns (incorrectly).
>
> Expansion of DataHelper supported conversions
> This one is not a JIRA issue, but a question I was reminded of when I
> saw a comment I'd left in the test case. In the second table on page
> 146 the Date conversions for most types are essentially to the same
> type, to Date, and to String. It seems that several more are
possible.
> The following seem capable of being added:
> DateTime-> Month, MonthDay, YearMonth, YearMonthDay, Time, Year,
> Duration, Day
> Duration->Month, MonthDay, YearMonth, YearMonthDay, Time, Year,
> DateTime, Day
> MonthDay->Month, Day
> YearMonth->Month, Year
> YearMonthDay->Month, Year, Day
>
>
> Thank you,
>
> Brian Murray
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
