Simon
thanks for spotting that. It has uncovered an issue which had me running
to my dictionary. The sample which uses integer indices to reference
property values relies on a statement in the SDO specification that says
"The order of Properties in Type.getDeclaredProperties() is the lexical
order of declarations in the XML Schema ComplexType", and for me that means
the order in which the properties would appear in a lexicon/dictionary. I
may be mistaken in my interpretation of the word, but I think the spec uses
"lexical" where it should use "literal" so for the sample we have a complex
type
<xsd:complexType name="EmployeeType">
<xsd:attribute name="name" type="xsd:string"/>
<xsd:attribute name="SN" type="xsd:ID"/>
<xsd:attribute name="manager" type="xsd:boolean"/>
</xsd:complexType>
and the sequence of the list returned by our implementation of
Type.getDeclaredProperties() is
name
SN
manager
i.e. the literal order. So it's unclear whether the problem lies with the
spec or the implementation. Given that I believe the use of the word
lexical in the spec elsewhere is taken to mean the literal order, I believe
there are two things to be fixed, one with the spec and the other with the
sample. This sample is an edge case and not something a user is very likely
to want to do (The most common use case for indexing by integer I would
imagine, is when using the generated integer indices that appear in
generated java classes, in which case this error would not occur). My
temptation is to drop this example for M2 and until the scope for confusion
has been removed.
Regards, Kelvin.
On 05/10/06, Simon Nash <[EMAIL PROTECTED]> wrote:
I'm getting the following error from the
AccessingDataObjectsViaPropertyIndex sample.
***************************************
SDO Sample AccessingDataObjectsViaPropertyIndex
***************************************
Demonstrates accessing the properties of a DataObject using property
indices.
***************************************
Defining Types using XSD
Type definition completed
Company DataObject:
[EMAIL PROTECTED] (eClass:
org.apache.tus
[EMAIL PROTECTED] (name: CompanyType) (instanceClassName:
null) (a
bstract: false, interface: false))
Company data object xml representation:
<?xml version="1.0" encoding="ASCII"?>
<company:company xmlns:company="company.xsd" name="ACME"
employeeOfTheMonth="E0001">
<departments name="Advanced Technologies" location="NY" number="123">
<employees name="John Jones" SN="E0001"/>
<employees name="Jane Doe" SN="E0003"/>
<employees name="A Varone" SN="E0004" manager="true"/>
</departments>
</company:company>
Setting name of company to MegaCorp
Removing employee A Varone from list of employees
Creating new employee (manager) Al Smith and adding to list
Sorry there was an error encountered java.lang.ClassCastException: The
value of type 'class java.lang.String' must be of type 'class
java.lang.Boolean'
java.lang.ClassCastException: The value of type 'class java.lang.String'
must be of type 'class java.lang.Boolean'
at
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettableStatic.validate
(EStructuralFeatureImpl.java:2195)
at
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettable.dynamicSet
(EStructuralFeatureImpl.java:2116)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(
BasicEObjectImpl.java:709)
at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(
DynamicDataObjectImpl.java:150)
at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(
DataObjectImpl.java:1442)
at org.apache.tuscany.sdo.impl.DataObjectImpl.set(
DataObjectImpl.java:103)
at
org.apache.tuscany.samples.sdo.specExampleSection.AccessingDataObjectsViaPropertyIndex.main
(AccessingDataObjectsViaPropertyIndex.java:206)
at org.apache.tuscany.samples.sdo.ExecuteSamples.main(
ExecuteSamples.java:143)
GoodBye
Simon
kelvin goodson wrote:
> I have made available an RC2 release candidate for SDO for Java at
> http://people.apache.org/~kelvingoodson/sdo_java/RC2/
>
> The main differences from RC1a are
>
> Tuscany JIRAs 115 and 755 are fixed
> The source distribution has been split (re-split) into specification and
> implementation archives after discussion on the tuscany-dev mailing list
> The samples are distributed as a separate standalone archive containing
> sample source code, java doc and all required binary artifacts.
> The EMF dependency jar is now the non-snapshot 2.2.1 version.
>
> Best Regards, Kelvin.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
