Hi Frank, Here is what I am after: 1. Input: XML Definition of SDO types 2. Create+Populate a DataGraph X compliant to the SDO Types 3. Get a 'SDO-enabled' JPA EntityManager, em 4. em.persist(X) 5. All the data should be persisted in a RDBMS
More about this in http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/persisting_ser v.html To do this, I need Java classes corresponding to SDO Types, because JPA works well with strongy-typed Java classes. These Java classes are generated on-the-fly by a byte code generation library. While it is not *important* for the dynamically generated Java classes to have package names, it just a Java-habit to add a package name:) I understand the non-kosher nature of things and according to your advice, encapsulated the package name extraction such that it does not statically depend on EMF. If possible it will get me a package name otherwise dynamically generated Java classes will remain in default name-less package. Thanks to you and this user group for help -- Pinaki Poddar 972.834.2865 -----Original Message----- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 1:25 PM To: [email protected] Subject: RE: Runtime access to sdoJava:package Hi Pinaki, As you said, what you're doing isn't very kosher. First, you shouldn't rely on EMF behavior, because it's subject to change and second, the EPackage name isn't always the same as the Java package, even though it is when sdoJava:package is specified. I don't really understand why you want this value anyway. It's only purpose (see SDO spec) is for the code generator to determine the java package for generated interfaces. It's meaningless information if you don't generate static SDOs, and if you do generate them, then getInstanceClass() will be non-null and you can get the value from it. Frank "Pinaki Poddar" <[EMAIL PROTECTED]> wrote on 07/10/2007 12:43:04 PM: > 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().get > Na > 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] > --------------------------------------------------------------------- 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]
