Hi,
Thanks for your help.
When the only input is a XML Schema, and SDO types are defined via:
List types = XSDHelper.INSTANCE.define(xsdInputStream,
schemaLocation);
The resultant types have non-null getInstanceClass() only when
type.isDataType()==true.
However, I have figured a way to access the sdoJava:package. May not be
kosher but here it is:
Runtime class of commonj.sdo.Type is
org.apache.tuscany.sdo.impl.ClassImpl.
This runtime class will reveal the underlying EMF implementaion's
Epackage.
For example, if 'po.xsd' defines a type named 'USAddress' and declares
sdoJava:package="com.acme.foo", then following test will pass:
public void testPackageNameIsAvailableViaDowncast() {
Type addressType = getType("USAddress");
assertTrue(addressType instanceof ClassImpl);
assertEquals("com.acme.foo",((ClassImpl)addressType).getEPackage().getNa
me());
}
And following tests will pass too:
public void testInstanceClassIsNullForUserType() {
Type addressType = getType("USAddress");
assertFalse(addressType.isDataType());
assertNull(addressType.getInstanceClass());
}
public void testInstanceClassIsNotNullForDataType() {
Type skuType = getType("SKU");
assertTrue(skuType.isDataType());
assertNotNull(skuType.getInstanceClass());
}
Pinaki Poddar
972.834.2865
-----Original Message-----
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 10, 2007 7:55 AM
To: [email protected]
Subject: RE: Runtime access to sdoJava:package
Given a Type, you can call type.getInstanceClass() and if it's not null,
the package name can be retrieved from the Class. If the instanceClass
is null, there is no static class, and hence no package for the type.
Frank.
"Pinaki Poddar" <[EMAIL PROTECTED]> wrote on 07/09/2007 05:53:21 PM:
> Thanks Fuhwei.
>
> But the underlying EMF Ecore allowed a path to do the same -- at least
> as far I can see in my debugger.
>
> In a implementation that is based upon another impl -- it often helps
> to make the underlying impl available via 'public Object
> getDelegate();' or some such method. Is there any such under-the-hood
> way to get hold of EMF impl classes in Tuscany's SDO impl -- even it
> does require me to cast to specific impl from the commonj.sdo API
instances.
>
>
> Pinaki Poddar
> 972.834.2865
>
> -----Original Message-----
> From: Fuhwei Lwo [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 09, 2007 4:46 PM
> To: [email protected]
> Subject: Re: Runtime access to sdoJava:package
>
> Hi Pinaki,
>
> sdoJava:package is only used by the users to control what Java package
> name should be generated during the generation of static SDO APIs. I
> don't think its info can be accessed from the standard SDO APIs.
>
> Fuhwei
>
> Pinaki Poddar <[EMAIL PROTECTED]> wrote: Hello, a newbie question:
> 1. *.xsd has declared
> sdoJava:package="com.acme.mydomain"
>
> 2. With XSDHelper.INSTANCE (or with some other helper)
> how does one programatically access the package name
> "com.acme.mydomain"?
>
> A more general question,
> does SDO Type has a 'package' notion or such notion is only valid if
> SDO Type is converted to Java Class?
>
> Thanks
>
>
> Pinaki Poddar
> 972.834.2865
>
>
> Notice: This email message, together with any attachments, may
> contain information of BEA Systems, Inc., its subsidiaries and
> affiliated entities, that may be confidential, proprietary,
> copyrighted and/or legally privileged, and is intended solely for the
> use of the individual or entity named in this message. If you are not
> the intended recipient, and have received this message in error,
> please immediately return this by email and then delete it.
>
> Notice: This email message, together with any attachments, may
> contain information of BEA Systems, Inc., its subsidiaries and
> affiliated entities, that may be confidential, proprietary,
> copyrighted and/or legally privileged, and is intended solely for the
> use of the individual or entity named in this message. If you are not
> the intended recipient, and have received this message in error,
> please immediately return this by email and then delete it.
>
> ---------------------------------------------------------------------
> 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]
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete
it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
