Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
Hi Ron, Looking at this, it looks like the problem is that you're trying to create dynamic subclasses of statically generated types. The bad news is that Tuscany doesn't currently support that. The good news is that it's not too hard to add the support. The problem is that currently Tuscany only has these two primary DataObject implementation classes: 1. DataObjectImpl - is the base class used for statically generated types. It is highly tuned for performance and footprint, so, unlike the base class in SDO1 (actually EMF) it doesn't support dynamic extensions. 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is designed for pure dynamic types, not a mixture of static and dynamic. To support what you want, we will need another base class, say ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, but doesn't make the assumption that eStaticFeatureCount() is 0. My guess is that there are only a few simple method overrides needed in this class. Maybe you would like to try to prototype such a class yourself and hand modify your generated classes to extend from it? If you did that and tested it, you could submit a patch and we could then very quickly add a generator option to use it (maybe even make it the default). If you'd like to help with this, it would be very much appreciated! At any rate, you should probably open a JIRA feature request for this. Thanks, Frank Ron Gavlin [EMAIL PROTECTED] wrote on 06/30/2006 10:13:44 AM: Frank, I am working with a mixed static/dynamic model similar to the one listed at the bottom of this post. The http://example.org/ord namespace is statically registered and has code-generated classes. The http://example.org/info/zipcode and http://example.org/info/street namespaces are dynamically registered with no code-generated classes. When I attempt to load the Sample Instance (chapter04.xml), I receive an UnsupportedOperationException thrown from DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the exception is an instance of InfoTypeImpl from the ord namespace/ePackage. The EClass parameter is InfoType from the zipcode namespace. This instance document loads fine using EMF/SDO 1.0. Any suggestions I can try to work-around this problem? - Ron Sample Instance (chapter04.xml) ord:order xmlns:ord=http://example.org/ord xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=http://example.org/ord chapter04ord1.xsd ord:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/size color value=blue/ /product /ord:items /ord:order Schema Document 1 (chapter04ord1.xsd) xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; targetNamespace=http://example.org/ord; xmlns=http://example.org/ord; xmlns:prod=http://example.org/prod; elementFormDefault=qualified xsd:import namespace=http://example.org/prod; schemaLocation=chapter04prod.xsd/ xsd:simpleType name=OrderNumType xsd:restriction base=xsd:string/ /xsd:simpleType xsd:complexType name=InfoType/ xsd:complexType name=CustomerType xsd:sequence xsd:element name=name type=CustNameType/ xsd:element name=number type=xsd:integer/ xsd:element name=info type=InfoType form=unqualified/ /xsd:sequence /xsd:complexType xsd:simpleType name=CustNameType xsd:restriction base=xsd:string/ /xsd:simpleType xsd:element name=order type=OrderType/ xsd:complexType name=OrderType xsd:sequence xsd:element name=number type=OrderNumType/ xsd:element name=customer type=CustomerType maxOccurs=unbounded/ xsd:element name=items type=prod:ItemsType/ /xsd:sequence /xsd:complexType /xsd:schema Schema Document 2 (chapter04infozipcode.xsd) xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:ord=http://example.org/ord; xmlns=http://example.org/info/zipcode; targetNamespace=http://example.org/info/zipcode; elementFormDefault=unqualified xsd:import namespace=http://example.org/ord; schemaLocation=chapter04ord1.xsd/ xsd:complexType name=InfoType xsd:complexContent xsd:extension base=ord:InfoType xsd:sequence xsd:element name=zipcode type=xsd:string/ /xsd:sequence /xsd:extension /xsd:complexContent /xsd:complexType /xsd:schema Schema Document 3 (chapter04infostreet.xsd) xsd:schema
Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
Off the top of my head, I think it will be very similar to what needed to be overridden in DynamicDataObjectImpl ... only in DynamicDataObjectImpl, the various eDynamicXXX method assume that the eStaticFeatureCount() method returns 0. I think that if you compare those method implementations to the way it is done in EObjectImpl (which is the SDO 1 base class), I think you'll see what optimizations were added in DynamicDataObjectImpl, based on the knowledge that there are no static features. Maybe DynamicDataObjectImpl and ExtensibleDataObjectImpl will have enough in common to make DynamicDataObjectImpl extend from ExtensibleDataObjectImpl. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 06/30/2006 12:35:21 PM: Hi Frank, I added JIRA feature request TUSCANY-513 to track this issue. Unfortunately, I don't think I have the EMF experience required to whip-up such a class. Off the top of your head, do you have an idea what methods the class would probably need to implement to get the job done? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Friday, June 30, 2006 12:05:34 PM Subject: Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException() Hi Ron, Looking at this, it looks like the problem is that you're trying to create dynamic subclasses of statically generated types. The bad news is that Tuscany doesn't currently support that. The good news is that it's not too hard to add the support. The problem is that currently Tuscany only has these two primary DataObject implementation classes: 1. DataObjectImpl - is the base class used for statically generated types. It is highly tuned for performance and footprint, so, unlike the base class in SDO1 (actually EMF) it doesn't support dynamic extensions. 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It is designed for pure dynamic types, not a mixture of static and dynamic. To support what you want, we will need another base class, say ExtensibleDataObjectImpl, that is quite similar to DynamicDataObjectImpl, but doesn't make the assumption that eStaticFeatureCount() is 0. My guess is that there are only a few simple method overrides needed in this class. Maybe you would like to try to prototype such a class yourself and hand modify your generated classes to extend from it? If you did that and tested it, you could submit a patch and we could then very quickly add a generator option to use it (maybe even make it the default). If you'd like to help with this, it would be very much appreciated! At any rate, you should probably open a JIRA feature request for this. Thanks, Frank Ron Gavlin [EMAIL PROTECTED] wrote on 06/30/2006 10:13:44 AM: Frank, I am working with a mixed static/dynamic model similar to the one listed at the bottom of this post. The http://example.org/ord namespace is statically registered and has code-generated classes. The http://example.org/info/zipcode and http://example.org/info/street namespaces are dynamically registered with no code-generated classes. When I attempt to load the Sample Instance (chapter04.xml), I receive an UnsupportedOperationException thrown from DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the exception is an instance of InfoTypeImpl from the ord namespace/ePackage. The EClass parameter is InfoType from the zipcode namespace. This instance document loads fine using EMF/SDO 1.0. Any suggestions I can try to work-around this problem? - Ron Sample Instance (chapter04.xml) ord:order xmlns:ord=http://example.org/ord; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://example.org/ord chapter04ord1.xsd ord:number123ABBCC123/ord:number ord:customer ord:namePat Walmsley/ord:name ord:number15465/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/zipcode; zipcode21043/zipcode /info /ord:customer ord:customer ord:namePriscilla Walmsley/ord:name ord:number15466/ord:number info xsi:type=ns1:InfoType xmlns= xmlns:ns1=http://example.org/info/street; street341 Duckworth Way/street /info /ord:customer ord:items product number557/number nameShort-Sleeved Linen Blouse/name size system=US-DRESS10/size color value=blue/ /product /ord:items /ord:order Schema Document 1 (chapter04ord1.xsd) xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;; targetNamespace=http://example.org/ord;; xmlns=http://example.org/ord;; xmlns:prod=http://example.org/prod;; elementFormDefault=qualified xsd:import namespace=http://example.org/prod;; schemaLocation=chapter04prod.xsd/ xsd:simpleType name=OrderNumType xsd:restriction base=xsd:string/ /xsd:simpleType xsd:complexType name=InfoType/ xsd:complexType name
Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException()
Ron Gavlin [EMAIL PROTECTED] wrote on 07/05/2006 10:09:51 AM: Greetings, In order to support mixed static/dynamic models, I made changes to SDOXSDEcoreBuilder as well as the changes listed in my previous message. I'm investigating whether I can contribute these back to the community. I'll let you know when I have more information. That would be great if you can. If so, open a JIRA for the issue and attach a patch. The changes made to SDOXSDEcoreBuilder could just as easily have been applied to EMF's EcoreBuilder. I think EMF itself would probably benefit from this mixed-model support. Since you haven't said exactly what your change to SDOXSDEcoreBuilder actually does, I can't really comment on whether or not it would be a good addition to EMF itself. If it's some kind of annotation to choose on a per-complexType basis whether to support a mixed dynamic/static base class, I think that since EMF currently has no static-only optimized base class, I'm not sure they'd want it there ... but you might want to suggest it on the EMF newsgroup to let them comment. Do you have any thoughts about modifying the code generator to support this new base class? Once we have the ExtensibleDataObjectImpl base class available, then I was thinking of a simple command line option (-extensible or something like that) to generate using it. This would apply to all the types, not the fine grain control you're suggesting below. Also any thoughts about offering the ability to INDIVIDUALLY flag/annotate specific schema types as extensible to enable code-generation optimizations? It doesn't sound like a bad idea if people would find it useful. Adding an annotation for this to the SDO spec would be harder since it's an implementation detail, but making it a Tuscany-specific extension shouldn't be a problem. - Ron - Original Message From: Ron Gavlin [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Friday, June 30, 2006 4:58:26 PM Subject: Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException() Frank, Thanks, that helped. I performed the following steps and the problem disappeared. 1. Added ExtensibleDataObject to the model (copied from DynamicDataObject) 2. Re-generated code from model into a work area and applied updates to relevant tuscany SDO classes [SDOFactory(Impl), SDOPackage(Impl)] 3. Copied DynamicDataObjectImpl to ExtensibleDataObjectImpl 4. Removed eStaticFeatureCount() method 5. Modified ExtensibleDataObjectImpl eStaticClass() and FactoryImpl. basicCreate to work with ExtensibleDataObjectImpls. 6. Modified my InfoTypeImpl class to extend ExtensibleDataObjectImpl instead of DataObjectImpl. 7. Executed XMLHelper load test to ensure the data object loads successfully using my mixed static/dynamic model...worked like a champ. What option were you thinking of adding to the code generator to trigger using this new base class? Along with this course-grained approach, does it also make sense to offer the ability to INDIVIDUALLY flag/annotate specific schema types as extensible? Is there a significant performance/memory win using a DataObjectImpl vs. ExtensibleDataObjectImpl? Thanks for all your help. - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Friday, June 30, 2006 2:17:58 PM Subject: Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException() A little more background: In EMF: 1. BasicEObjectImpl is a base implementation of the EObject interface. It doesn't allocate any storage - it expects subclasses to do that. 2. EObjectImpl is the EMF default base class for generated classes. It is a flexible implementation that allows the generated classes to be extended by dynamic types. 3. DynamicEObjectImpl extends EObjectImpl to optimize a few things for the pure-dynamic case. 4. EDataObjectImpl is a subclass of EObjectImpl that also implements the SDO DataObject interface - in Tuscany we don't have separate implementation classes to implement the DataObject interface because all our implementation classes are for that purpose. in Tuscany: 1. DataObjectImpl is a subclass of EMF's BasicEObjectImpl that implements the DataObject interface and allocates the absolute minimum storage. Unlike EObjectImpl, which is an analous class for EMF (EObject's), it is not intended to be extended by dynamic types. 2. DynamicDataObjectImpl is analogous to DynamicEObjectImpl in EMF, but for DataObjects. So, the ExtensibleDataObjectImpl class I've suggested is something between DataObjectImpl and DynamicDataObjectImpl that would be the DataObject equivalent of EObjectImpl. I hope this helps. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 06/30/2006 01:12:58 PM: Frank, Does the proposed relationship between ExtensibleDataObjectImpl and DataObjectImpl
Fw: XMLHelper.save() specifying default namespace of root element
Ron, I forwarded your question to Ed Merks (the top EMF guru) and here's his reply. Frank. - Forwarded by Frank Budinsky/Toronto/IBM on 07/07/2006 10:21 AM - Ed Merks/Toronto/IBM 07/07/2006 10:13 AM To Frank Budinsky/Toronto/[EMAIL PROTECTED] cc Subject Re: Fw: XMLHelper.save() specifying default namespace of root element Frank, Yes, direct manipulation of the DOM that's produced by default is really the only way right now.This is definitely a hard/expensive problem to solve since XMLSaveImpl is very much geared around emitting all the unique prefixes right at the top. (That being said, where there's a will there's a way. ;-) Ed Merks/Toronto/[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] 905-413-3265 (t/l 969) Frank Budinsky/Toronto/IBM 07/07/2006 09:51 AM To Ed Merks/Toronto/[EMAIL PROTECTED] cc Subject Fw: XMLHelper.save() specifying default namespace of root element Ed, Can you answer this. I think I'm over my head now :-) Thanks, Frank. - Forwarded by Frank Budinsky/Toronto/IBM on 07/07/2006 09:51 AM - Ron Gavlin [EMAIL PROTECTED] 07/07/2006 09:47 AM Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org cc Subject Re: XMLHelper.save() specifying default namespace of root element Hi Frank, Unfortunately, one of the child elements/DataObjects of the DataObject I'm saving has a form=unqualified. So, it needs to be serialized with a 'xmlns=' which didn't happen. I guess this is a scoping issue with the XMLNSPrefixMap that probably cannot be easily solved, right? Do you think my best bet is to convert my DataObject to a DOM Document, set a default namespace and remove the prefix namespace on the document element, then recursively navigate through the elements and rename those within that default namespace to remove their prefix? Any other ideas? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 6, 2006 6:51:55 PM Subject: Re: XMLHelper.save() specifying default namespace of root element Ron, EMF lets you control the xmlns prefixes by setting the XMLNSPrefixMap of the DocumentRoot, but SDO has no concept of DocumentRoot so it's hidden in the implementation. To support this in Tuscany, a line of code like this is needed in the XMLDocumentImpl ctor: ((EMap)documentRoot.eGet(extendedMetaData.getXMLNSPrefixMapFeature(documentRootClass))).put(, rootElementURI); It may be possible to add an option in the Tuscany implementation of the XMLHelper.save() method to do this. How important is it to you? Does anybody else think this sounds like a good feature to add? Note that you need to be a little bit careful when using the default namespace if your schema declares qualified form elements, for example. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 07/06/2006 12:49:22 PM: When I invoke XMLHelper.INSTANCE.save(), I would like the ability to make the namespace I specify for the root element the default namespace for the resulting document. Currently, a namespace and prefix are defined for the root element and all nodes from that namespace are specified using that prefix. Is there any way to trigger use of a default namespace to accomplish this? Also, I noticed that Jeremy has a class DOMHelperImpl in his sandbox that looks like it can be used to efficiently load/save DataObjects from/to DOM nodes. This looks like a useful utility class. Any plans to formally support this type of functionality in Tuscany SDO? - Ron - 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] - 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]
Re: SDOXMLResourceImpl.load(Node, Map) problems
Ron,
Nothing obvious jumps out. Loading from DOM should work the same as from
a stream. You'll just need to debug it, or if you can provide a simple
JUnit that illustrates the problem, I can take a look.
Frank.
Ron Gavlin [EMAIL PROTECTED] wrote on 07/07/2006 01:09:11 PM:
Hi,
See below.
- Original Message
From: Frank Budinsky [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Friday, July 7, 2006 9:39:24 AM
Subject: Re: SDOXMLResourceImpl.load(Node, Map) problems
Ron Gavlin [EMAIL PROTECTED] wrote on 07/07/2006 12:23:48 AM:
Using EMF/SDO 1.0, we were able to use XMLResourceImpl's load and
save methods to transform between DataObjects and DOM Nodes. The
same technique is no longer working with Tuscany SDO 2.0. For
example, when I invoke SDOXMLResourceImpl.load(Node, null), a
DynamicEObjectImpl is created instead of a DataObjectImpl. Any ideas
off the top of your head how to make this work?
My guess is that you tried this in an environment where the SDO runtime
wasn't initialized. Usually that happens automatically, under the
covers,
when you use SDO features, but you can force it by calling
DataObjectUtil.
initRuntime().
RG
In this case, I am initializing the runtime before running the test.
Here's the code. I highlighted where I am receiving the
ClassCastException. Do you have any thoughts?
// initialize SDO runtime, define types, load document
...
org.w3c.dom.Element element = document.getDocumentElement();
DataGraphImpl dataGraph = (DataGraphImpl) SDOUtil.createDataGraph();
SDOXMLResourceImpl doResource = (SDOXMLResourceImpl) dataGraph.
getRootResource();
doResource.unload();
ExtendedMetaData extendedMetaData = ((TypeHelperImpl) TypeHelper.
INSTANCE).getExtendedMetaData();
DataObjectUtil.configureXMLResource(doResource, extendedMetaData);
// this is required by my mixed static/dynamic model which include
xsi:type
doResource.getDefaultLoadOptions().put(XMLResource.
OPTION_USE_DEPRECATED_METHODS, Boolean.TRUE);
doResource.load(element, null);
if (!doResource.getContents().isEmpty())
{
// ClassCastException here -- DynamicEObjectImpl returned instead
of DataObjectImpl
DataObject rootObject = (DataObject) doResource.getContents().get(0);
SDOUtil.setRootObject(dataGraph, rootObject);
}
return dataGraph;
/RG
Of course, we would rather not resort to EMF APIs to efficiently
convert between DataObjects and DOM Nodes. But EMF APIs are better
than paying the performance penalty of using Strings or Input/Output
Streams as an intermediate representation. It would be nice if SDO
or Tuscany provided XMLHelper-like save/load methods that took DOM
Nodes in addition to Strings and Streams. Assuming we can get the
SDOXMLResourceImpl load/save problems mentioned above resolved,
would it make sense to use EMF's load/save capabilities to provide
load/save services for DOM nodes? Would SDOUtil, DataObjectUtil, a
Tuscany DOMHelper, or another class be the right location for such
methods?
I would stay away from calling the EMF APIs directly, if I were you. As
Raymond mentioned, in his reply, the plan is to add an API to use
Source/Result for this. That API has been agreed for addition to the 2.1
version of the SDO spec. In the meantime, however, we could add
something
to SDOUtil in Tuscany. Maybe if you want to speed things up, you could
write the SDOUtil method for this and contribute it to the project?
One of the reasons we need DOM Nodes from SDO DataObjects is so we
can perform XML Schema validation. Another reason we transform
between DataObjects and DOM Nodes is to interact with our web services
engine.
Thanks in advance for your help.
- Ron
-
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]
-
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]
Re: How should XSDHelper.define() handle wsdls/schemas with schema imports
Ron, You are right that you only need the second argument of define() if your schemaLocation argument is a relative path, e.g.: location=a.xsd. If your location is an absolute path that can be located and opened as with an InputStream, then you don't need to specify the second argument. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 07/14/2006 09:48:43 AM: Frank, My WSDL import includes an absolute schema location. In this case, do I still need to pass the schemaLocation (second argument) to XSDHelper.define()? I'm not exactly sure what you mean by an absolute location from which the imported schemaLocations can be resolved. Is this specifically relevant in this case where the imported schemaLocation uses a relative reference, say './b.xsd' or 'b.xsd'. Here, the schemaLocation argument would need to be used to absolutely reference say 'http://myserver/a.xsd' or 'http://myserver', such that 'b.xsd' exists in the same directory as 'a.xsd'? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Friday, July 14, 2006 9:10:16 AM Subject: Re: How should XSDHelper.define() handle wsdls/schemas with schema imports Ron, I believe that the XSDHelper.define() method had been tested in the past, but since we don't have an official JUnit for that, it could possibly be broken now. But, I think it's more likely that either the WSDL2JavaGenerator is causing the problem, or maybe the imported schema b just can't be resolved. Does the WSDL import include a schema location. You can easily test XSDHelper.define() by calling it with the WSDL file, and then iterating through the list of Type's that it returns to make sure that it includes types in both URIs a and b, Make sure that when you call define() you pass it a schemaLocation String (second argument) that is an absolute location from which the imported schemaLocations can be resolved. Good luck. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 07/14/2006 08:36:10 AM: Frank et al., Do you know if the scenario in which a WSDL with targetNamespace a imports a schema with targetNamespace b has been tested? The WSDL2JavaGenerator doesn't seem to handle this scenario. I'm not sure if it is a XSDHelper problem or a WSDL2JavaGenerator problem. - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Thursday, July 13, 2006 2:45:18 PM Subject: Re: How should XSDHelper.define() handle wsdls/schemas with schema imports XSDHelper.define() should also define all the imported schemas. If that's not happing, maybe the imported schemas can't be found so it's failing to resolve. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 07/13/2006 01:16:59 AM: I have a WSDL which imports a schema, that itself imports two add'l schemas. When I invoke XSDHelper.define() passing the WSDL as a parameter, should the nested schema imports be resolved/defined or do each of these imported schemas need to be defined explicitly? It appears the WSDL2JavaGenerator currently expects XSDHelper.define() to resolve/define the imported schemas which does not appear to work. Best regards, - Ron - 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] - 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] - 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]
Re: Eclipse EMF bug 152166 impact on Tuscany SDO
Hi Ron, We're one step ahead of you :-) We've already switched our pom files to pick up weekly SNAPSHOT builds from EMF. So we should pick up this fix starting today. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 08/03/2006 07:07:08 AM: Greetings, I bumped into EMF bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=152166 (XML loader namespace-scoping problems) during my Tuscany SDO usage that proved to be a show-stopper for us. The bug was fixed in EMF 2. 2.1-M20060803. Do you have plans to build/test with the latest EMF milestone releases or will you stick with stable releases? Since EMF is such an integral part of the Tuscany SDO implementation, we would like to see the latest EMF code incorporated in your interim builds, a little like EMF/SDO currently works. Regards, - Ron - 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]
Re: java.lang.ClassCastException using TypeHelper
Philipp, This error is usually means that the SDO runtime has not been initialized. Usually it happens as a side effect of accessing SDO helpers, but generated classes often have this problem. We're hopefully going to come up with a good way to avoid this in the future, but for now you can force initialization by calling DataObjectUtil.initRuntime() at the very start of your program. Frank. Philipp Schöpf [EMAIL PROTECTED] wrote on 08/03/2006 01:32:00 PM: Hi, I am encountering strange problems with the actual tuscany build (I got it from subversion this day) . This is what happens when I try to determine the type of my DataObject, calling myDataObject.getType(): java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EClassImpl at org.apache.tuscany.sdo.impl.DataObjectImpl. getType(DataObjectImpl.java:190) I tried working around this using the Typehelper on my object, but this led to a similar error, calling TypeHelper.INSTANCE. getType(myDataObject.class);: java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EClassImpl at org.apache.tuscany.sdo.helper.TypeHelperImpl. getType(TypeHelperImpl.java:98) Btw, my DataObject class was generated from Xsd with the XSD2JavaGenerator. I am using the actual EMF 2.2.1 snapshot downloaded by maven during build. Btw, I never tried the same with the M1 build, should I? Any hints? Thanks in advance, Philipp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSD2Java-generated interfaces are not Serializable
Hi Ron, OK, I just made your suggested change (revision 436855). We'll see if anyone complains :-) Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 08/23/2006 07:36:31 PM: Hi Frank, Yes, that would solve the problem. My only concern is that -interfaceDataObject is proposed as an optional flag. If it isn't specified, I think the generated interfaces should extend Serializable nevertheless. All types of Data Transfer Objects, including SDO DataObjects, should be Serializable. - Ron Frank Budinsky wrote: Hi Ron, Would the feature described in TUSCANY-254 be acceptable, or is that more than you want. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 08/23/2006 03:32:52 PM: Hi Frank, Now that you have returned from vacation, do you have any thoughts on this issue? FYI, the session bean in question is a remote session bean. Thanks in advance, - Ron - Original Message From: Ron Gavlin [EMAIL PROTECTED] To: tuscany-user tuscany-user tuscany-user@ws.apache.org Sent: Monday, August 14, 2006 12:44:08 PM Subject: XSD2Java-generated interfaces are not Serializable Greetings, I have a session bean that includes XSD2Java-generated interfaces as return types and method parameters. My appserver complains that these interfaces are not Serializable. The XSD2Java-generated implementation classes are indeed serializable. How should this problem be solved...should XSD2Java make these interfaces extend Serializable or do I need to specify the implementation classes as return types and method parameters? - Ron - 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] - 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]
Re: Instantiate static SDOs with DataFactory
Hi Erich, It definitely should work, so I suspect that there may be something funny about your environment, or maybe we've broken something lately. Are you using the latest Tuscany code? Frank Erich Rueede [EMAIL PROTECTED] 12/15/2006 09:08 AM Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org cc Subject Instantiate static SDOs with DataFactory Hi all, I'm referring to Philipp Schöpfs questions about instantiating a static SDO through the DataFactory.INSTANCE.create(Person.class) method. This works without exception for me BUT the actual object created is not static but dynamic (DynamicDataObjectImpl) and therefore it cannot be type- casted to Person. I actually expected a PersonImpl to be returned... So the question is: Is it possible to use the dynamic API to create an SDO and then subsequently switch to a static type of processing? This actually works with the EMF-based SDO 1.0 implementation. Thanks, Erich __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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]
SDO/XSD Fidelity
In the SDO collaboration workgroup meeting yesterday, it was agreed that improved XSD fidelity is an important issue that needs to be addressed to make SDO successful in the web services use case. A JIRA issue for this, attached below, has been opened in the SDO collaboration JIRA database, and will be one of the high priority items to be discussed. Although the issue is targeted for SDO 3, the collaboration has also discussed the possibility of producing an earlier 2.2 release which might include a subset of the 3.0 resolutions, if some (like this issue may be) are considered too important to wait for SDO 3. What we need help with is formulation and clarification of the issues. What XML constructs are awkward, or even impossible, to work with using SDO? Please check the list of known items below and let me know if you have additional ones or comments on the existing issues. Any specific preferences about how any of these issues are addressed would also be very welcome. Thanks, Frank. SDO-197: Improved SDO/XSD Fidelity Using SDO to represent web service data is an important SDO use case. Since XSD is the type system, SDO must provide good fidelity with XSD in order to be successful in this application. SDO already provides good support for XSD, but by simplifying the user model SDO has made a few common features of XSD difficult, if not impossible, to work with. The objective of this feature is to ensure that SDO provides good fidelity/support for all XSD features found in common industrial schemas, and to also ensure that SDO also provides a fallback mechanism for handling the remaining XSD corner cases. This feature will be used to create and discuss the list of issues that need to be considered, after which separate issues will be opened to address the individual fixes/changes that we ultimately decide need to be made. The following lists the issues known so far. Please add any new issues that you know of, or add comments/clarifications for the existing issues. the . character in Type and Property names must be completely supported (issue SDO-187 to address this) support duplicate property names allowed by separate XSD namespaces for attributes and elements - handing of @ in SDO XPath (issue SDO-192 opened for this) XSD facet constraints and validation support xsd:key/xsd:keyref handling/support improved handling of xsd:restriction derivation? improved handling of xsd:choice? consistent fallback strategy (e.g., open/sequenced dynamic DataObject) for handling XSD corner cases - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem importing schema
Hi Emiliano, I guess the error messages could be a little better :-) The problem is that when you have a file with imports, the import in the .xsd file typically includes a relative file name for where to find the .xsd file with the imported types in it. To make that work, the loader needs the file location (schemaLocation) for the referencing (main) file. That's why you can't pass null for the second argument of XSDHelper.define() when you are loading a .xsd file with imports. The other way you tried to do it: XSDHelper.INSTANCE.define(baseXsd, http://www.example.org/BaseSchema;); didn't work either because you were passing a schema namespace URI, not the schema location. If you look at some of the JUnit tests in the sdo impl project you'll see the recommended pattern for calling define. For example, SimpleDynamicTestCase does this: URL url = getClass().getResource(TEST_MODEL); InputStream inputStream = url.openStream(); XSDHelper.INSTANCE.define(inputStream, url.toString()); It passes in the file location that corresponds to the InputStream being loaded. Frank. emiliano grigis [EMAIL PROTECTED] wrote on 12/21/2006 05:35:15 AM: Hi, I have a problem with an xml file based on a schema with a type that is imported from another schema. I think that the problem it's into the schemaLocation parameter on the define method. Of course if I use the value null for both the schemaLocation, like: XSDHelper.INSTANCE.define(baseXsd, null); XSDHelper.INSTANCE.define(sampleXsd, null); then I receive a FeatureNotFoundException: Feature 'baseElement' not found. (http:///temp.xml, 4, 18) exception when loading the xml document. If I specify the schemaLocation option like this: XSDHelper.INSTANCE.define(baseXsd, http://www.example.org/BaseSchema;); XSDHelper.INSTANCE.define(sampleXsd, null); then I have a java.lang.IllegalArgumentException: org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl without further explanations. Many thanks in advance Emiliano The Java code: //base.xsd //Schema with only a type definition InputStream baseXsd = Thread.currentThread() .getContextClassLoader().getResourceAsStream( base.xsd); //sample.xsd //Schema that import the type definition from the other xsd InputStream sampleXsd = Thread.currentThread() .getContextClassLoader().getResourceAsStream( sample.xsd); //sample.xml //document conform to the sample.xsd InputStream sampleXml = Thread.currentThread() .getContextClassLoader().getResourceAsStream( sample.xml); //Load the Schemas XSDHelper.INSTANCE.define(baseXsd, http://www.example.org/BaseSchema;); XSDHelper.INSTANCE.define(sampleXsd, null); System.out.println(-- Schemas read); //Load xml XMLDocument xDoc = XMLHelper.INSTANCE.load(sampleXml); System.out.println(-- Xml read); The base.xsd source: ?xml version=1.0 encoding=UTF-8? schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace= http://www.example.org/BaseSchema; xmlns:base= http://www.example.org/BaseSchema; complexType name=baseType sequence element name=baseElement type=string minOccurs=1 maxOccurs=1/ /sequence /complexType /schema The sample.xsd source: ?xml version=1.0 encoding=UTF-8? schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace= http://www.example.org/SampleSchema; xmlns:sample= http://www.example.org/SampleSchema; xmlns:base= http://www.example.org/BaseSchema; import namespace=http://www.example.org/BaseSchema; schemaLocation= base.xsd/ complexType name=sampleType sequence element name=sampleElement type=base:baseType/element /sequence /complexType element name=myElement type=sample:sampleType/element /schema The sample.xml source: ?xml version=1.0 encoding=UTF-8? sample:myElement xmlns:base=http://www.example.org/BaseSchema; xmlns:sample=http://www.example.org/SampleSchema; xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://www.example.org/SampleSchema sample.xsd http://www.example.org/BaseSchema base.xsd sampleElement baseElementthis is my content/baseElement /sampleElement /sample:myElement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem importing schema
On more thing that I forgot to mention is that you don't actually need to call XSDHelper.define() for base.xsd because it will be automatically defined when you define simple.xsd (because of the import). Frank. emiliano grigis [EMAIL PROTECTED] wrote on 12/21/2006 05:35:15 AM: Hi, I have a problem with an xml file based on a schema with a type that is imported from another schema. I think that the problem it's into the schemaLocation parameter on the define method. Of course if I use the value null for both the schemaLocation, like: XSDHelper.INSTANCE.define(baseXsd, null); XSDHelper.INSTANCE.define(sampleXsd, null); then I receive a FeatureNotFoundException: Feature 'baseElement' not found. (http:///temp.xml, 4, 18) exception when loading the xml document. If I specify the schemaLocation option like this: XSDHelper.INSTANCE.define(baseXsd, http://www.example.org/BaseSchema;); XSDHelper.INSTANCE.define(sampleXsd, null); then I have a java.lang.IllegalArgumentException: org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl without further explanations. Many thanks in advance Emiliano The Java code: //base.xsd //Schema with only a type definition InputStream baseXsd = Thread.currentThread() .getContextClassLoader().getResourceAsStream( base.xsd); //sample.xsd //Schema that import the type definition from the other xsd InputStream sampleXsd = Thread.currentThread() .getContextClassLoader().getResourceAsStream( sample.xsd); //sample.xml //document conform to the sample.xsd InputStream sampleXml = Thread.currentThread() .getContextClassLoader().getResourceAsStream( sample.xml); //Load the Schemas XSDHelper.INSTANCE.define(baseXsd, http://www.example.org/BaseSchema;); XSDHelper.INSTANCE.define(sampleXsd, null); System.out.println(-- Schemas read); //Load xml XMLDocument xDoc = XMLHelper.INSTANCE.load(sampleXml); System.out.println(-- Xml read); The base.xsd source: ?xml version=1.0 encoding=UTF-8? schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace= http://www.example.org/BaseSchema; xmlns:base= http://www.example.org/BaseSchema; complexType name=baseType sequence element name=baseElement type=string minOccurs=1 maxOccurs=1/ /sequence /complexType /schema The sample.xsd source: ?xml version=1.0 encoding=UTF-8? schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace= http://www.example.org/SampleSchema; xmlns:sample= http://www.example.org/SampleSchema; xmlns:base= http://www.example.org/BaseSchema; import namespace=http://www.example.org/BaseSchema; schemaLocation= base.xsd/ complexType name=sampleType sequence element name=sampleElement type=base:baseType/element /sequence /complexType element name=myElement type=sample:sampleType/element /schema The sample.xml source: ?xml version=1.0 encoding=UTF-8? sample:myElement xmlns:base=http://www.example.org/BaseSchema; xmlns:sample=http://www.example.org/SampleSchema; xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://www.example.org/SampleSchema sample.xsd http://www.example.org/BaseSchema base.xsd sampleElement baseElementthis is my content/baseElement /sampleElement /sample:myElement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Frank Budinsky/Toronto/IBM is out of the office.
I will be out of the office starting 12/21/2006 and will not return until 01/02/2007. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making the SDO SCA schemas available via internet
Hi Dan, I've heard that a more general problem is that the namespace URIs that SDO uses for its standard types: commonj.sdo commonj.sdo/xml commonj.sdo/java are problematic since they are not absolute URIs and according to some WS spec are not really valid, so some web servers completely ignore them. If that is true, then SDO is going to need to make a change to use proper absolute URIs for these namespaces. For example: http://www.osoa.org/2007/sdo; http://www.osoa.org/2007/sdo/xml; http://www.osoa.org/2007/sdo/java; Then you won't need to include a schemaLocation, since the imported namespaces themselves will be available on the internet. I guess the first step is to open an issue with the SDO specification and see what results. Frank Dan Murphy [EMAIL PROTECTED] wrote on 01/08/2007 10:40:41 AM: Do'oh what a muppet (I am)... didn't think of that, though the url is not the most memorable, it fixes my immediate concern... thanks Pete :) Anyone from the OSOA collab around who can raise this? Dan On 08/01/07, Pete Robbins [EMAIL PROTECTED] wrote: On 08/01/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, I like to keep my (eclispe) workspaces free of red x's (errors) and make use of content assistance where ever possible. As a result I keep copying the various SDO and SCA schema files to different projects and workspaces. An alternative I've tried is to directly reference the schemas location in subversion, eg http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo- api/src/main/resources/xml/sdoModel.xsd However, this means that when schemas change existing XML files could become invalid. For example, SDO 3's schema could introduce a change that is not backwards compatible. Is there any desire to fix this by hosting a copy (or linking to a specific subversion revision) off the main tuscany site url, for example: http://incubator.apache.org/tuscany/schemas/sdo/2.1.0/sdoModel.xsd. Alternatively does (or should) OSOA.org host them somewhere (I can't find any links). Either way I think it would be a good idea to have SDO and SCA schemas available directly off the internet... WDYT? Cheers, Dan I think ultimately they should be available from OSOA site. Can you just link into the svn src tree in the tag for the release you are using? Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem w/SDO xsd:dateTime value being validated using EMF Diagnostician.validate()
I don't know if it worked in SDO 1 either, but a big change in this area
is that the xsd types now map to commonj.sdo types as descirbed in the SDO
2 spec. In SDO 1, they mapped to types in the EMF XMLTypePackage.
In SDO 2 (Tuscany), xsd:dateTime maps to this type (defined in
sdoModel.xsd):
xsd:simpleType name=DateTime sdoJava:instanceClass=java.lang.String
xsd:restriction base=xsd:dateTime/
/xsd:simpleType
It, along with all of the commonj types, is generated in class
org.apache.tuscany.sdo.model.impl.ModelFactoryImpl. I don't know how the
EMF validator will handle this type.
Frank.
Ron Gavlin [EMAIL PROTECTED]
01/16/2007 01:05 PM
Please respond to
tuscany-user@ws.apache.org
To
tuscany-user tuscany-user tuscany-user@ws.apache.org
cc
Subject
Problem w/SDO xsd:dateTime value being validated using EMF
Diagnostician.validate()
Greetings,
I have an xsd:dateTime child element in an XML Schema that I use to
statically generate Tuscany SDO classes. Since Tuscany does not currently
provide a schema validation API, I have been using EMF to accomplish this
task using the following code:
...
Diagnostic diagnostic =
Diagnostician.INSTANCE.validate((EObject)
myDataObjectwithDateTimeChildProperty);
if (diagnostic.getSeverity() == Diagnostic.ERROR)
{
throw new Exception(diagnostic.getChildren().toString());
}
This technique works fine for most schema validation issues, like min/max
facet length enforcement for child xsd:strings, etc. However, EMF is
performing no validation against my Tuscany DateTime field (I can supply a
bogus dateTime and no diagnostic error is generated). Is this an EMF
problem or a Tuscany/EMF integration problem? I thought this used to work
with the Eclipse EMF-based SDO 1.0 implementation but I may be wrong. Any
suggestions would be greatly appreciated.
Thanks in advance,
- Ron
-
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]
Re: Problem w/SDO xsd:dateTime value being validated using EMF Diagnostician.validate()
Ron, you seem to be contradicting yourself. First you said it should not validate: I would think it makes sense for the SDO deserializer to behave like a non-validating XML parser. and then you said it should: should the SDO 2 Deserializer validate an xsd:dateTime like the EMF-based SDO 1 did? I think yes. Anyway, I think I agree with Yang. For performance reasons, we probably should not validate during deserialization, and leave it to an explicit validation request. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 01/21/2007 05:34:52 PM: So, should the SDO 2 Deserializer validate an xsd:dateTime like the EMF-based SDO 1 did? I think yes. Do you agree? - Ron Yang ZHONG wrote: Agree with Ron: 1. Deserializer (and setters) don't want to validate since not each user is fine with the performance drawback 2. provide standalone validation On 1/19/07, Ron Gavlin [EMAIL PROTECTED] wrote: Hi Frank, Thanks for getting back to me. I would think it makes sense for the SDO deserializer to behave like a non-validating XML parser. Then SDO validation would behave much like an XML validator. What do you think? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Friday, January 19, 2007 2:29:34 PM Subject: Re: Problem w/SDO xsd:dateTime value being validated using EMF Diagnostician.validate() Hi Ron, You're right about the difference between SDO 1 and 2. The instanceClass for SDO 1 xsd:dateTime was XMLCalendar, which enforces valid values when setting (deserializing). Since SDO 2 uses String for the instanceClass, there's no automatic enforcement. The SDO spec doesn't really say anything about whether an implementation should do immediate validation on things like this, or if it should be deferred until a validator is run. This question, and the more general issue of validation, is one of the items that is planned for SDO 3. As far as Tuscany is concerned, we could do validation in this case by adding validation code in the method XMLFactoryImpl.createDataTimeFromString(), assuming that is consistent with the SDO 3 direction. For complete (deferred) validation, Tuscany can either implement it using EMF (as you suggest) or we may be able to write a pure SDO validator, once we make facet constraints available with SDO APIs - i.e., as soon as we finish implementing the new 2.1 feature: getInstanceProperties() and get(Property) on Type and Property. The later approach is more work, but consistent with our goal of trying not to rely on EMF being used in the implementation of SDO. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 01/19/2007 09:39:40 AM: Hi Kelvin/Frank, Do either of you have any thoughts or insights re: the questions I raised in my prior note? Thanks in advance for your assistance, - Ron - Original Message From: Ron Gavlin [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Wednesday, January 17, 2007 9:38:08 AM Subject: Re: Problem w/SDO xsd:dateTime value being validated using EMF Diagnostician.validate() Thanks for the reply, Frank. I believe in EMF SDO 1, loading a DataGraph with an invalid xsd: dateTime value behaved much like loading a DataGraph with an invalid xsd:integer. Here, xsd:dateTime fields were parsed into EMF XMLCalendar instances and therefore parsing errors were reported at load time. Tuscany SDO does not behave this way. Does the fact that the SDO spec states that xsd:dateTime gets rendered as a String imply that parsing should not be performed at load time and therefore invalid xsd:dateTime values ignored? Does the SDO spec plan to address validation in a later revision? If Tuscany SDO were to support validation, do you think Tuscany would roll its own validation, use the validation capabilities built-in to EMF, or use the EMFT Validation Framework? Would it be appropriate for me to create a JIRA to document this enhancement request? I was thinking of writing a ModelValidator that is responsible for validating the types defined in ModelPackageImpl. It would delegate to EMF's DynamicEDataValidator for some types and implement custom validation for others like DateTime. In order to implement this capability, I would register the ModelPackageImpl and ModelValidator with the EMF EValidatorRegistry. Does this seem like a reasonable approach? Where do you think it would make most sense to perform this registration? - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Tuesday, January 16, 2007 3:24:59 PM Subject: Re: Problem w/SDO xsd:dateTime value being validated using EMF Diagnostician.validate() I don't know if it worked in SDO 1 either, but a big change
Re: java.lang.ClassCastException org.eclipse.emf.ecore.util.EcoreEList$Dynamic incompatible with commonj.sdo.DataObject
I'm guessing that the property that your calling getList() for is single
valued. You can only call getList() on a property if the property has
Property.isMany == true. In other words, there's no automatic conversion
from a single valued property value to List.
Frank.
Christian Landbo Frederiksen [EMAIL PROTECTED]
wrote on 01/29/2007 03:24:42 PM:
Hi
I just ran into a classcast exception when I tried to call getList on a
dataobject.
I searched a bit for it and found this in the samples:
PurchaseOrderControl.removeItem(int index) {
// TODO: this is not working due to
java.lang.ClassCastException:
// org.eclipse.emf.ecore.util.EcoreEList$Dynamic incompatible
with commonj.sdo.DataObject
// access a DataObject by the index and then remove it
Can anybody tell more about this?
/Chr
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: SDO (Types) Registry
Christian, I don't think your scenario is beyond the purpose of SDO - In fact, I see it as a real world example that we should try to accommodate. To provide an option that allows you to overwrite/replace existing types, would not be difficult to do - but it would be dangerous to use if, for example, you have instances of the types at the time you change them. Also, you could end up with corrupt models if, for example, you delete a type that is referenced by another. What about serialized XML instances? If you change a type and then try to load a serialized XML, unless the types are a compatible extension (i.e., only new things added), it may no longer conform to the schema. What level of versioning does this requirement imply? Would it be acceptable if this option was a use at own risk feature - the user needs to be very careful when using it? I realize that, as an SDO/EMF novice, you may have a hard time finding the right places in the code that need to change, so we can help with that, if we agree exactly what we're trying to implement. Frank. Christian Landbo Frederiksen [EMAIL PROTECTED] wrote on 02/12/2007 01:40:25 PM: Let me first say, I don't not have very much insight into how Tuscany is built up. I am dealing with a situation where the xsd's, that define the format of a generic data publishing sysem, can be added and changed dynamically - even the individual types of a namespace can be changed (probably not very often). I first looked into EMF XSD and then found Tuscany, and it has looked very promising. Except that I ran into the fact that namespaces cannot be altered once defined. Frank Budinsky came up with a solution where namespaces can be extended, but the types that exist already in a namespace cannot be redefined. Perhaps this scenario is way beyond the purpose of SDO, but besides these two issues I find it very useful to work with runtime xml schemas. So as you might guess I think an option to totally redefine namespaces or to extend them with new types and just overwrite the existing ones, would be fine. This is in fact something I am trying to look into implement myself, but at the understanding I'm at now I am having difficulties maneuvering in the EMF. I have no idea where defined schemas are currently kept in the VM and therefore don't know where to put in the code to allow types of a namespace to be redefined. Any pointers to where this code would go would be GREAT... /Chr -Original Message- From: kelvin goodson [mailto:[EMAIL PROTECTED] Sent: 10. februar 2007 13:27 To: tuscany-user@ws.apache.org Subject: Re: SDO (Types) Registry Christian, unfortunately not. The only open JIRA we have in this area is http://issues.apache.org/jira/browse/TUSCANY-761 for unregistering all the types in a namespace. Perhaps we could collect together some info on what's really useful here and have some design discussions on how to handle type lifecycle. There have previously been discussions on forming associations between HelperContexts so that one HC can have dependencies on another/others. This might allow for example dropping type definitions by dropping all references to a given HelperContext. It would be good to know exactly which operations would be the most valuable to you in order to help make good design decisions. Regards, Kelvin. On 10/02/07, Christian Landbo Frederiksen [EMAIL PROTECTED] wrote: Is there no way to 'undefine' types if you have to modify existing types? /Chr From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: Fri 2/9/2007 5:10 PM To: tuscany-user@ws.apache.org Subject: RE: SDO (Types) Registry If the requirement is just to add new types to a namespace, as opposed to modifying existing types (which is nasty), I don't think it would be hard to add this support. This is open source, maybe you want to help :-) Initially, I would suggest adding a new instance variable in XSDHelperImpl - extensibleNamespaces (false by default, but can be set to true) - and then change this line in XSDHelperImpl.define(): if (ePackage == null || TypeHelperImpl.getBuiltInModels ().contains(ePackage)) to this: if (extensibleNamespaces || ePackage == null || TypeHelperImpl. getBuiltInModels().contains(ePackage)) Then, it's a matter of debugging to make sure that in SDOXSDEcoreBuilder, when a type is requested that already exists, it just uses the existing type and moves on. New types would get added in the usual way. I think this may be related to, and helped by, the work that will be done in TUSCANY-1085 (not the patch provided by Fuhwei, but the proper fix that needs to be done), which needs to ensure that previously loaded types are found in SDOXSDEcoreBuilder. Frank. Christian Landbo Frederiksen [EMAIL PROTECTED] wrote on 02/09
Re: how to activate changesummary
Hi,
This is one of the messy parts of SDO that is still in the process of
being cleaned up. Currently an sdo:datagraph maps to the java interface
commonj.sdo.DataGraph, not commonj.sdo.DataObject, so you cannot load it
using XMLHelper like show below. In Tuscany we have a special method
SDOUtil.loadDataGraph() that you can use, but this is not a standard SDO
API. In the future, the plan is to make a DataGraph also be a DataObject,
so then you will be able to load it using XMLHelper.
Note that you can associate a ChangeSummary with a graph of objects in
either of two ways:
1) put the data objects into a commonj.sdo.DataGraph.
2) create a type with a ChangeSummary-type property and use it as the root
data object.
For examples of how to work with DataGraphs and ChangeSummarys, I would
suggest looking at the following JUnit test in sdo/impl/src/test/java:
org.apache.tuscany.sdo.test.ChangeSummaryOnDataObjectTestCase
org.apache.tuscany.sdo.test.ChangeSummaryPropertyTestCase
org.apache.tuscany.sdo.test.ChangeSummaryTestCase
org.apache.tuscany.sdo.test.DataGraphTestCase
Frank.
Veselin Vasilev [EMAIL PROTECTED] wrote on 02/20/2007 10:52:41 AM:
Hello ,
I have the following example :
How can I create or activate a ChangeSummary (mine is always null)
I am using the following code that loads an xml file.
DataObject datagraph = *null*;
*try* {
FileInputStream stream = *new* FileInputStream(xmlFileName2);
datagraph =
XMLHelper.*INSTANCE*.load(stream).getRootObject();
} *catch* (Exception ex) {ex.printStackTrace();}
DataObject company = datagraph.getDataObject(company);
// Access the company DataObject from the company property of
// the root object.
DataObject rootObject = datagraph.getRootObject();
System.*out*.println(DG CHANGE SUM IS NuLL ? + (
datagraph.getChangeSummary() == *null*));
and the xml is :
sdo:datagraph xmlns:company=company.xsd
xmlns:sdo=commonj.sdo
company:company name=ACME employeeOfTheMonth=E0002
departments name=Advanced Technologies location=NY
number=123
employees name=John Jones SN=E0001/
employees name=Mary Smith SN=E0002 manager=true/
employees name=Jane Doe SN=E0003/
/departments
/company:company
/sdo:datagraph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO - XML Schema element with default attribute behaves as if nillable=true
Hi Ron, The serialization behavior is based on isSet() behavior, so you should be concerned abou it :-) A property is serialized only if isSet() is true. The SDO 2.1 design is that isSet() returns true if the property has been set (period). Unlike EMF, it has nothing to do with the default value. So if you set to null (valid or not), isSet will return true and you'll get an element serialized and xsi.nil will be used to represent a null value. We've already implemented this behavior in Tuscany. Frank. P.S. Another new feature in SDO 2.1 is Property.isNullable() to determine whether or not null is a valid value for a property. We haven't implemented this in Tuscany yet. Ron Gavlin [EMAIL PROTECTED] wrote on 03/06/2007 11:56:22 AM: Hi Frank, Thanks for the quick reply. I'm less concerned about the actual isSet() behavior and more concerned with 1. serialization and 2. the behavior of unset() vs. set(null). In M2, when nillable = false, unset() and set(null) behave similarly in that both adhere to the same serialization semantics. OTOH, when nillable = true, unset serializes as an absent element whereas set(null) serializes w/xsi:nil=true. The presence of a default attribute triggers the nillable = true serialization semantics. How is this supposed to work in SDO 2.1? How does it work currently in the Tuscany SVN head? How will it work in Tuscany M3? Thanks in advance. - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Tuesday, March 6, 2007 11:39:23 AM Subject: Re: SDO - XML Schema element with default attribute behaves as if nillable=true What specifically do you mean by: makes the SDO runtime treat quantity as if the element also had the attribute, nillable=true. If you're referring to the behavior of isSet() after you call set(null), then this is a feature inherited from EMF. If a property was a default value, the property becomes EMF-unsettable, so isSet() will always return true after set(). The fact that null is not a legal value (since the type is not nillable) is a validation issue. Note that in SDO 2.1, all features will behave this way - even the ones without default value. There was a clarification in semantics of isSet in the 2.1 SDO spec, so this EMF-specific behavior will no longer apply. Frank Ron Gavlin [EMAIL PROTECTED] wrote on 03/06/2007 11:13:51 AM: Greetings, I am using the M2 SDO release. Assume I have registered a schema that includes the following snippet: ... xs:element name=item maxOccurs=unbounded xs:complexType xs:sequence xs:element name=title type=xs:string/ xs:element name=note type=xs:string minOccurs=0/ xs:element name=quantity type=xs:nonNegativeInteger minoccurs=0 default=0 / xs:element name=price type=xs:decimal/ /xs:sequence /xs:complexType /xs:element ... It appears the presence of a default attribute on the quantity element makes the SDO runtime treat quantity as if the element also had the attribute, nillable=true. Is this a bug? If so, I'll be happy to register a JIRA issue. Let me know. - Ron - 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] - 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]
Re: SDO - XML Schema element with default attribute behaves as if nillable=true
Hi Ron, You asked me about this about a month ago, and here was my answer: SDO 2.1 has added a new method for this, Property.isNullable(). Unfortunately we haven't implemented in yet in Tuscany (it currently throws UnsupportedOperationException if you call it). The implementation plan is to add an EAnnotation on EStructuralFeatures created in SDOXSDEcoreBuilder, to store the nillable value, and then use that EAnnotation to implement the new isNullable() method. It's not on our high priority list but If you'd like to do it and provide a patch, that would be most welcome. Thanks, Frank. So, if you'd like to help, we can get this finished very soon :-) Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 03/06/2007 01:38:35 PM: Hi Frank, Thanks for clearing this issue up for me. I appreciate it. Now that Tuscany has implemented this new SDO 2.1 design, it seems pretty important to support Property.isNullable(). Is there a JIRA # for this issue? Is it planned for M3? For us, the SDO 2.1 behavior may prove problematic without it. Thanks again, - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Tuesday, March 6, 2007 12:14:38 PM Subject: Re: SDO - XML Schema element with default attribute behaves as if nillable=true Hi Ron, The serialization behavior is based on isSet() behavior, so you should be concerned abou it :-) A property is serialized only if isSet() is true. The SDO 2.1 design is that isSet() returns true if the property has been set (period). Unlike EMF, it has nothing to do with the default value. So if you set to null (valid or not), isSet will return true and you'll get an element serialized and xsi.nil will be used to represent a null value. We've already implemented this behavior in Tuscany. Frank. P.S. Another new feature in SDO 2.1 is Property.isNullable() to determine whether or not null is a valid value for a property. We haven't implemented this in Tuscany yet. Ron Gavlin [EMAIL PROTECTED] wrote on 03/06/2007 11:56:22 AM: Hi Frank, Thanks for the quick reply. I'm less concerned about the actual isSet() behavior and more concerned with 1. serialization and 2. the behavior of unset() vs. set(null). In M2, when nillable = false, unset() and set(null) behave similarly in that both adhere to the same serialization semantics. OTOH, when nillable = true, unset serializes as an absent element whereas set(null) serializes w/xsi:nil=true. The presence of a default attribute triggers the nillable = true serialization semantics. How is this supposed to work in SDO 2.1? How does it work currently in the Tuscany SVN head? How will it work in Tuscany M3? Thanks in advance. - Ron - Original Message From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Tuesday, March 6, 2007 11:39:23 AM Subject: Re: SDO - XML Schema element with default attribute behaves as if nillable=true What specifically do you mean by: makes the SDO runtime treat quantity as if the element also had the attribute, nillable=true. If you're referring to the behavior of isSet() after you call set(null), then this is a feature inherited from EMF. If a property was a default value, the property becomes EMF-unsettable, so isSet() will always return true after set(). The fact that null is not a legal value (since the type is not nillable) is a validation issue. Note that in SDO 2.1, all features will behave this way - even the ones without default value. There was a clarification in semantics of isSet in the 2.1 SDO spec, so this EMF-specific behavior will no longer apply. Frank Ron Gavlin [EMAIL PROTECTED] wrote on 03/06/2007 11:13:51 AM: Greetings, I am using the M2 SDO release. Assume I have registered a schema that includes the following snippet: ... xs:element name=item maxOccurs=unbounded xs:complexType xs:sequence xs:element name=title type=xs:string/ xs:element name=note type=xs:string minOccurs=0/ xs:element name=quantity type=xs:nonNegativeInteger minoccurs=0 default=0 / xs:element name=price type=xs:decimal/ /xs:sequence /xs:complexType /xs:element ... It appears the presence of a default attribute on the quantity element makes the SDO runtime treat quantity as if the element also had the attribute, nillable=true. Is this a bug? If so, I'll be happy to register a JIRA issue. Let me know. - Ron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
Re: EclipseLink-SDO/DAS Tuscany-SDO/DAS
Hi Ron, The EclipseLink project won't impact the work being done here, unless at some point the community decides that there may be interesting interoperability or collaborative things worth pursuing. Given the lack of technical details right now, all I can say is that having more implementations is good for SDO. Note that there are also several other non-open source implementations of SDO out there. Frank Ron Gavlin [EMAIL PROTECTED] wrote on 03/08/2007 11:58:19 AM: Greetings, Any thoughts on how the introduction of EclipseLink-SDO EclipseLink-DAS might impact the SDO/DAS work being done here in Tuscany? ( http://www.oracle.com/technology/tech/eclipse/pdf/eclipselink-faq.pdf ). Are EclipseLink and Tuscany likely to co-exist well into the future as competing, open source SDO DAS implementations (one bundled with Oracle Fusion middleware and the other bundled with IBM WebSphere middleware)? How expected was the EclipseLink announcement? Regards, - Ron - 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]
RE: ConcurrentModificationException Disconnected DataGraphs
The departments property is a containment reference - not a simple
cross-reference (pointer). A DataObject can only have a single container,
so SDO specifies that if you add an object to a containment reference, it
is automatically removed from its previous container, if it has one.
You could define a non-containment property and set two of those to point
to a single object, but using it in a way that crosses DataGraphs is also
not allowed. SDO DataGraphs are supposed to be self contained - any
non-containment references in a DataGraph need to point to objects that
are contained in the same DG.
Frank
Murtaza Goga [EMAIL PROTECTED] wrote on 03/20/2007 12:09:28
PM:
Maybe I confused the issue with the way I had coded it. I want to add a
reference to the 'department' object in the two disconnected DataGraphs.
I was calling DataObject.detach to remove the container reference. The
test case will fail with the same exception if you comment out the
detach.
I am not removing objects, I am adding objects. At the end of the test
case I would have expected to see companyA to have 1 department and
companyB to have 2 departments. The only way we are able to work around
this is by making a copy of the object as follows:
for (Iterator iter = departments_A.iterator(); iter.hasNext();) {
DataObject department_A = (DataObject) iter.next();
departments_B.add(CopyHelper.INSTANCE.copy(department_A));
}
This is the failing test code fragment:
for (Iterator iter = departments_A.iterator(); iter.hasNext();) {
DataObject department_A = (DataObject) iter.next();
departments_B.add(department_A);
}
I hope this clarifies the use case and question.
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 11:54 AM
To: tuscany-user@ws.apache.org
Subject: Re: ConcurrentModificationException Disconnected DataGraphs
Murtaza,
This is just a standard Java programming issue. You can't remove objects
in a List while you have an active Iterator, unless you use
Iterator.remove().
In your example, instead of this:
department_A.detach();
you would need to call:
iter.remove();
to remove the department from the list and inform the Iterator of the
change.
Frank
Murtaza Goga [EMAIL PROTECTED] wrote on 03/20/2007
11:24:34
AM:
We have two disconnected DataGraphs and when we add DataObjects from
one
DataGraph into the other (with or without 'detach' being called) we
are
observe ConcurrentModificationExceptions. I have pasted a simple test
case below which adds a 'department' from one company into another.
This test case will error out with the above exception. The
company.xsd
is from the Tuscany M3 RC1 build.
Can someone explain this behavior and what should be the recommended
usage pattern?
/**
* @see junit.framework.TestCase#setUp()
*/
@Override
protected void setUp() throws Exception {
XSDHelper.INSTANCE.define(ClassLoader
.getSystemResourceAsStream(company.xsd), null);
}
/**
* Test list usage.
*/
public void test01Concurrency() {
DataGraph dataGraph_A = createCompanyDataGraph(1);
DataGraph dataGraph_B = createCompanyDataGraph(1);
List departments_A =
dataGraph_A.getRootObject().getList(departments);
List departments_B =
dataGraph_B.getRootObject().getList(departments);
for (Iterator iter = departments_A.iterator(); iter.hasNext();) {
DataObject department_A = (DataObject) iter.next();
department_A.detach(); // Does not matter if this call is made
or
not
departments_B.add(department_A);
}
}
/**
* Creates the company datagraph.
* @param departmentsToCreate the number of departments to create.
* @return the DataGraph.
*/
private DataGraph createCompanyDataGraph(int departmentsToCreate) {
DataGraph dataGraph = SDOUtil.createDataGraph();
dataGraph.createRootObject(company.xsd, CompanyType);
for (int i = 0; i departmentsToCreate; i++) {
dataGraph.getRootObject().createDataObject(departments,
company.xsd,
DepartmentType);
}
return dataGraph;
}
Thanks,
Murtaza.
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom static SDOs with formatter and validation logic
Hi Erich, The Tuscany SDO generator is currently reusing the code generator framework from Eclipse EMF project. If you look at the EMF generator, you'll see that it's very powerful and customizable. In Tuscany all we've done is create a simple command line invocation of the EMF generator, using our own templates, and a few basic options. One thing we don't support is regen/merge because the EMF merger prereqs the Eclipse JDT, which we didn't want to drag into Tuscany as a dependency. If someone is willing to write a standalone merger for Tuscany, we could support regen. Other things like generating a different base class or adding methods, are supported in EMF but we don't have a way do it in with the Tuscany generator yet. If you'd be willing to help get some of this function into Tuscany, I'm sure a lot of people would be interested in it. The bottom line is that real sophisticated tooling is outside of the scope of the Tuscany project. Another possible direction for this is for some Eclipse project to provide a fancy GUI-generator (and possibly other tools) for developing Tuscany SDO applications. It would be nice to see something like that get started. Thanks, Frank Erich Rueede [EMAIL PROTECTED] wrote on 03/24/2007 10:14:20 AM: Hi Kelvin, if I understand you correctly, there is currently no supported way of extending generated SDO implementation classes: 1) I cannot have my own superclass of a generated SDO class since this is already occupied 2) I cannot (yet) simply subclass a generated SDO class, this may be addressed in TUSCANY-513 As a consequence I would have to modify the generated SDO implementation class in order to offer custom formatter and validation logic!? Is there eventually a way to inject code using annotations? Or is it possible to re-generate and prevent override of custom code (merge)? Thanks Erich --- kelvin goodson [EMAIL PROTECTED] wrote: Erich, there's a number of ways you could be trying to extend SDO generated classes. You might be wanting to make a new SDO Type which uses the generated base class as an SDO basetype. If so then that's the subject of http://issues.apache.org/jira/browse/TUSCANY-513, which I was hoping to address at one time, but haven't got to it yet. If you want to override existing behaviour, I don't believe there are any specific hook points we expose to facilitate that currently, e.g. template method patterns. If I understand correctly, the -storePattern is there due to the store pattern that was implemented in the eclipse implementation of SDO 1.0 which was an implementation feature which allowed you to override the gets and sets of properties to a store instance (for example I used this to allow lazy instantiation using XML pull parsing) -- this kind of feature is coming up for discussion in the SDO 3 spec effort, but isn't a functional part of the current Tuscany SDO implementation. Regards, Kelvin. On 19/03/07, Erich Rueede [EMAIL PROTECTED] wrote: Hi, I'm trying to figure out how I extend a generated static Java SDO with additional features, such as my own custom formatting an validation methods. Are there some hooks, that could be used for this subject? Will the generator's -storePattern eventually help? Thanks, Erich The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news - 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]
Re: XSD2JavaGenerator J2SE 1.5
Unfortunately not. The current version of SDO, version 2.1, is Java 1.4
based, so we need to work without generics. An option to generate
generics would be possible, but we haven't got it yet.
Frank.
Murtaza Goga [EMAIL PROTECTED] wrote on 03/27/2007 08:01:00
AM:
Is it possible to generate methods of the form:
List[javaType] get[propertyName]();
I am using the generator against company.xsd with M3-RC1.
public interface CompanyType extends Serializable
{
List getDepartments();
...
}
would like:
public interface CompanyType extends Serializable
{
ListDepartmentType getDepartments();
...
}
Are there any hidden options or schema annotations to get the generics
in?
Thanks,
Murtaza.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: SDO Java M3 Release Candidate RC1
Hi Christian,
Your schema seems to be using http:// schemaLocations. For performance
reasons, we recently disabled that, but I guess we really shouldn't do
that, without it being an option. We will fix it in the next driver.
If you want to try it out yourself, the fix is to comment out line 2473 in
DataObjectUtil:
//resourceSet.setURIConverter(new SDOURIConverterImpl());
Frank.
Christian Landbo Frederiksen [EMAIL PROTECTED]
wrote on 03/27/2007 03:51:43 AM:
Hi again.
Though my simple testcase now functions, I have run into a nullpointer
exception with a schema that functions in M2.
java.lang.NullPointerException
at
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
oreBuilder.java:123)
As far as I can tell: In BaseSDOXSDEcoreBuilder:
protected EStructuralFeature createFeature
(EClass eClass, XSDElementDeclaration xsdElementDeclaration,
String name, XSDComponent xsdComponent, intminOccurs, int
maxOccurs) {
XSDTypeDefinition elementTypeDefinition =
getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
The call to getEffectiveTypeDefinition returns null, resulting in the
nullpointer in the next call to
EClassifier eClassifier = getEClassifier(elementTypeDefinition);
The schema has references to other schemas and it is in the first of
those (StreetName) it fails.
This is the schema I try to define:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:brugerinformation=http://rep.oio.dk/brugerinformation.dk/xml/sche
mas/2007/01/01/
xmlns:XKOM=http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/;
xmlns:DKCC=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/;
xmlns:DKCC2=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/;
targetNamespace=http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
/01/01/ elementFormDefault=qualified xml:lang=en
import
namespace=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/;
schemaLocation=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_PostCodeIdentifier.xsd/
import
namespace=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/;
schemaLocation=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_DistrictName.xsd/
import
namespace=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/;
schemaLocation=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_StreetName.xsd/
import
namespace=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/;
schemaLocation=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
_StreetBuildingIdentifier.xsd/
import
namespace=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/;
schemaLocation=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_DistrictSubdivisionIdentifier.xsd/
import
namespace=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/;
schemaLocation=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
_FloorIdentifier.xsd/
import
namespace=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/;
schemaLocation=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKCC
_SuiteIdentifier.xsd/
annotation
documentation/
/annotation
element name=InstitutionAddress
type=brugerinformation:InstitutionAddressType/
complexType name=InstitutionAddressType
sequence
element name=DaycareServiceName
type=string/
element ref=DKCC:StreetName/
element ref=DKCC2:StreetBuildingIdentifier/
element ref=DKCC2:FloorIdentifier
minOccurs=0/
element ref=DKCC2:SuiteIdentifier
minOccurs=0/
element ref=DKCC:PostCodeIdentifier/
element ref=DKCC:DistrictName/
element
ref=DKCC:DistrictSubdivisionIdentifier/
element name=InstitutionPhonenrText
type=string/
element name=EmailaddText type=string/
element name=WeblinkText type=string/
/sequence
/complexType
/schema
Any ideas?
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: 26. marts 2007 19:12
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
You need to get your DataFactory from the HelperContext:
DataObject documentDataObject = hc.getDataFactory().create(namespace,
DocumentRoot);
You should generally stop using INSTANCE fields in all cases, because
they
are probably going to be deprecated in the next version of SDO.
HelperContext is the replacement. It defines a metadata scope, so you
should always use it to get the helpers for your scope.
Frank.
Christian Landbo Frederiksen [EMAIL PROTECTED]
wrote on 03/26/2007 01:01:00 PM:
In M2 M3 this works for a specific schema:
XSDHelper.INSTANCE.define(new String(xsdFile.getBytes(UTF-8)));
DataObject documentDataObject = DataFactory.INSTANCE.create(namespace,
DocumentRoot);
But this doesn't
HelperContext hc = SDOUtil.createHelperContext(true
Re: Confusion about SDO's
SDO is a specification developed by an industry consortium (OSOA). The current version of the specification is 2.1 and can be found at http://osoa.org. Several companies have implementations of SDO in their products including: BEA, IBM, Oracle, SAP, RogueWave, XCalia. IBM's implementation of SDO version 1 was done at Eclipse, but that project has since been deprecated and moved to Apache (Tuscany). Tuscany is currently implementing SDO 2.1. There is also an Oracle implementation of SDO that was recently proposed for Eclipse (the EclipseLink project). It will also be SDO 2.1, but with different features and performance characteristics than Tuscany. In terms of standardization, SDO for Java is going to be standardized via the JCP (JSR 235). Other languages are moving to OASIS. Frank. António Mota [EMAIL PROTECTED] wrote on 03/27/2007 10:24:51 AM: Can someone please enlight me about these SDO things? I've worked in a project a year ago where i used IBM RAD with JSF and SDO Relational Records and Relational Record Lists. At that time i searched the web for material and found almost nothing valuable, but i did got the impression that SDO was a proprietary technology that IBM and Oracle and a few other minor players decided to implement without the approval of the JCP/Sun and so it was not part of J2EE. I did found the technology to be very interesting, but due to the lack of support and information (among other factors) the work did not went well and was interrupted in the middle. Now, one year after, i suggested again the use of IBM RAD with JSF and SDO in a shop that works almost exclusively with IBM technologies. Despite my bad experience with it. But i found that the information and support still doesn't practically exist. However, now i found references to SDO not only with IBM and Oracle, but also in relation to some other vendors, PHP, and more confusing with Eclipse and Apache... Oh, and OSOA too.. So my question is, is all these SDO the same thing? Are IBM and Oracle and Eclipse and Apache developing the same thing in different ways? Did they all centralized the development in Apache? If so, IBM RAD have older versions of SDO or their own implementation? I think it's all too confusing... -- Melhores cumprimentos / Best regards António Santos Mota - 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]
Re: DAS error after upgrading code to recent revision
I'm just guessing here, but maybe the DAS Config model hasn't been regenerated with the latest SDO. There have been some significant changes in SDO in the last couple of months, so downstream models definitely need to be regenerated to work with the latest runtime. Frank. Marilene Noronha Roder [EMAIL PROTECTED] wrote on 03/27/2007 07:55:38 PM: Hello I did an upgrade of the SDO/DAS code base and now the companyweb.CompanyClient DAS sample and some other of my test programs that use Tuscany DAS are failing with this exception: Would anyone have any insigth of what could be causing this? Thanks Marilene N Roder Exception in thread main java.lang.ExceptionInInitializerError at java.lang.J9VMInternals.initialize(*J9VMInternals.java:195*) at sun.misc.Unsafe.ensureClassInitialized(*Native Method*) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(* UnsafeFieldAccessorFactory.java:43*) at sun.reflect.ReflectionFactory.newFieldAccessor(*ReflectionFactory.java :150*) at java.lang.reflect.Field.acquireFieldAccessor(*Field.java:945*) at java.lang.reflect.Field.getFieldAccessor(*Field.java:926*) at java.lang.reflect.Field.get(*Field.java:385*) at org.apache.tuscany.sdo.util.SDOUtil.registerStaticTypes(*SDOUtil.java:813 *) at org.apache.tuscany.das.rdb.util.ConfigUtil.loadConfig(*ConfigUtil.java:48 *) at org.apache.tuscany.das.rdb.impl.DASImpl.init(*DASImpl.java:62*) at org.apache.tuscany.das.rdb.impl.DASFactoryImpl.createDAS(* DASFactoryImpl.java:31*) at org.apache.tuscany.samples.das.companyweb.CompanyClient.init(* CompanyClient.java:36*) at companyweb.CompanyWebTest.main(*CompanyWebTest.java:57*) Caused by: * org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException*: index=0, size=0 at org.eclipse.emf.common.util.BasicEList.get(*BasicEList.java:512*) at org.apache.tuscany.das.rdb.config.impl.ConfigFactoryImpl.initializeMetaData( *ConfigFactoryImpl.java:480*) at org.apache.tuscany.das.rdb.config.impl.ConfigFactoryImpl.init(* ConfigFactoryImpl.java:370*) at org.apache.tuscany.das.rdb.config.ConfigFactory.clinit(* ConfigFactory.java:28*) at java.lang.J9VMInternals.initializeImpl(*Native Method*) at java.lang.J9VMInternals.initialize(*J9VMInternals.java:177*) ... 12 more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java M3 Release Candidate RC1
I'm also wondering if you only see this problem when you create your
HelperContext using SDOUtil.createHelperContext(true), or if it also
happens in the false case?
There have been a number of changes in the SDO implementation lately that
might be causing this problem. So, as Kelvin said, a test case
illustrating the problem would be much appreciated.
Thanks,
Frank.
kelvin goodson [EMAIL PROTECTED] wrote on 03/28/2007 03:53:21
AM:
Hi Christian,
could you please post some code snippets or better still a test case.
It
appears that the Type that you are trying to create an instance of is
associated with an EMF factory rather than an SDO Factory.
On the subject of HelperContext lifecycle, there's no constraint on the
longevity of a HelperContext instance. At the moment I imagine that
each
instance would be relatively long lived, since there are no fine
grained
controls on the lifecycle of the Types within a scope. So I imagine
that
for many applications a single HelperContext will suffice for the
lifetime
of the application.
It may be the case that in the future we provide ways of associating
HelperContexts in order that one may delegate to another/others. I can
imagine in that scenario more opportunities to control the type system
by
having short lived HelperContext instances, but as I say, we don't
have
that yet.
Regards, Kelvin.
On 27/03/07, Christian Landbo Frederiksen
[EMAIL PROTECTED] wrote:
Hi Frank et. al.
I applied the fix and it helped, but I also get an error like the one
mentioned in this thread (NullPointerException), when a referenced
schema cannot be found!
But that is not the worst part. Once I run into that error, all later
attempts to create using a dataFactory from the context also fail, but
this time with the following error:
java.lang.ClassCastException:
org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with
commonj.sdo.DataObject
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
a:61)
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
a:46)
Any ideas?
Could you describe some helpercontext scenarios? I am specifically
wondering how long the helperContext instance should live. Currently I
am trying to use a long living context inside a singleton - imagining
it
is the most efficient way. Is that recommendable?
/Chr
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: 27. marts 2007 16:27
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
Hi Christian,
Your schema seems to be using http:// schemaLocations. For performance
reasons, we recently disabled that, but I guess we really shouldn't do
that, without it being an option. We will fix it in the next driver.
If you want to try it out yourself, the fix is to comment out line
2473
in
DataObjectUtil:
//resourceSet.setURIConverter(new SDOURIConverterImpl());
Frank.
Christian Landbo Frederiksen
[EMAIL PROTECTED]
wrote on 03/27/2007 03:51:43 AM:
Hi again.
Though my simple testcase now functions, I have run into a
nullpointer
exception with a schema that functions in M2.
java.lang.NullPointerException
at
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
oreBuilder.java:123)
As far as I can tell: In BaseSDOXSDEcoreBuilder:
protected EStructuralFeature createFeature
(EClass eClass, XSDElementDeclaration xsdElementDeclaration,
String name, XSDComponent xsdComponent, intminOccurs, int
maxOccurs) {
XSDTypeDefinition elementTypeDefinition =
getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
The call to getEffectiveTypeDefinition returns null, resulting in
the
nullpointer in the next call to
EClassifier eClassifier = getEClassifier(elementTypeDefinition);
The schema has references to other schemas and it is in the first of
those (StreetName) it fails.
This is the schema I try to define:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:brugerinformation=http://rep.oio.dk/brugerinformation.dk/xml/sche
mas/2007/01/01/
xmlns:XKOM=http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/;
xmlns:DKCC=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/;
xmlns:DKCC2=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/;
targetNamespace=http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007
/01/01/ elementFormDefault=qualified xml:lang=en
import
namespace=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/;
schemaLocation=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKCC
_PostCodeIdentifier.xsd/
import
namespace=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/;
schemaLocation=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03
RE: SDO Java M3 Release Candidate RC1
);
} catch (Exception e) {
e.printStackTrace();
throw e;
}
} catch (Exception e) {
fail(e.toString());
}
}
public void test(final String xsdFile, final String rootElement,
final String namespace) throws Exception {
System.out.println(Calling define...);
this.helperContext.getXSDHelper().define(new
String(xsdFile.getBytes(ISO-8859-1)));
System.out.println(Define successful...);
System.out.println(Calling create...);
this.helperContext.getDataFactory().create(namespace,
rootElement + Type);
System.out.println(Create successful...\n);
return;
}
}
-- END COPY
-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: 28. marts 2007 09:53
To: tuscany-user@ws.apache.org
Subject: Re: SDO Java M3 Release Candidate RC1
Hi Christian,
could you please post some code snippets or better still a test case.
It
appears that the Type that you are trying to create an instance of is
associated with an EMF factory rather than an SDO Factory.
On the subject of HelperContext lifecycle, there's no constraint on the
longevity of a HelperContext instance. At the moment I imagine that
each
instance would be relatively long lived, since there are no fine
grained
controls on the lifecycle of the Types within a scope. So I imagine
that
for many applications a single HelperContext will suffice for the
lifetime
of the application.
It may be the case that in the future we provide ways of associating
HelperContexts in order that one may delegate to another/others. I can
imagine in that scenario more opportunities to control the type system
by
having short lived HelperContext instances, but as I say, we don't
have
that yet.
Regards, Kelvin.
On 27/03/07, Christian Landbo Frederiksen
[EMAIL PROTECTED] wrote:
Hi Frank et. al.
I applied the fix and it helped, but I also get an error like the one
mentioned in this thread (NullPointerException), when a referenced
schema cannot be found!
But that is not the worst part. Once I run into that error, all later
attempts to create using a dataFactory from the context also fail, but
this time with the following error:
java.lang.ClassCastException:
org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with
commonj.sdo.DataObject
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
a:61)
at
org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.jav
a:46)
Any ideas?
Could you describe some helpercontext scenarios? I am specifically
wondering how long the helperContext instance should live. Currently I
am trying to use a long living context inside a singleton - imagining
it
is the most efficient way. Is that recommendable?
/Chr
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: 27. marts 2007 16:27
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
Hi Christian,
Your schema seems to be using http:// schemaLocations. For performance
reasons, we recently disabled that, but I guess we really shouldn't do
that, without it being an option. We will fix it in the next driver.
If you want to try it out yourself, the fix is to comment out line
2473
in
DataObjectUtil:
//resourceSet.setURIConverter(new SDOURIConverterImpl());
Frank.
Christian Landbo Frederiksen
[EMAIL PROTECTED]
wrote on 03/27/2007 03:51:43 AM:
Hi again.
Though my simple testcase now functions, I have run into a
nullpointer
exception with a schema that functions in M2.
java.lang.NullPointerException
at
org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEClassifier(SDOXSDEc
oreBuilder.java:123)
As far as I can tell: In BaseSDOXSDEcoreBuilder:
protected EStructuralFeature createFeature
(EClass eClass, XSDElementDeclaration xsdElementDeclaration,
String name, XSDComponent xsdComponent, intminOccurs, int
maxOccurs) {
XSDTypeDefinition elementTypeDefinition =
getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
The call to getEffectiveTypeDefinition returns null, resulting in
the
nullpointer in the next call to
EClassifier eClassifier = getEClassifier(elementTypeDefinition);
The schema has references to other schemas and it is in the first of
those (StreetName) it fails.
This is the schema I try to define:
?xml version=1.0 encoding=UTF-8?
schema xmlns=http://www.w3.org/2001/XMLSchema;
xmlns:brugerinformation=http://rep.oio.dk/brugerinformation.dk/xml/sche
mas/2007/01/01/
xmlns:XKOM=http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/;
xmlns:DKCC=http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/;
xmlns:DKCC2=http://rep.oio.dk/ebxml
RE: SDO Java M3 Release Candidate RC1
It looks like we sometimes leave the type registry in a corrupt state
after a type fails to resolve.
Frank.
Christian Landbo Frederiksen [EMAIL PROTECTED]
wrote on 03/28/2007 12:35:31 PM:
Ok I'll do that - but do you know why this happens after something has
failed on otherwise correct schemas?
/Chr
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: 28. marts 2007 17:03
To: tuscany-user@ws.apache.org
Subject: RE: SDO Java M3 Release Candidate RC1
Christian,
This is definitely a bug. It is supposed to treat elements of
unresolved
types as anyType, but we seem to have missed a couple of guards for
null (unresolved) type in our XSDEcoreBuilder subclass.
Please open a JIRA, and we will fix it soon.
Thanks,
Frank.
Christian Landbo Frederiksen [EMAIL PROTECTED]
wrote on 03/28/2007 09:47:02 AM:
Hi Kelvin
I can't seem to find out precisely what causes it, because I can
generate a test case where this does not occur.
Fortunately I can also generate one where it does.
Let me first say that if I create a new helperContext when the
IllegalArgumentException occurs the problem can be avoided...
Since I am not sure how else to supply this I have just done a
copy/paste og the test case (JUnit 3.8):
--- COPY ---
package dk.test;
import junit.framework.TestCase;
import org.apache.tuscany.sdo.util.SDOUtil;
import commonj.sdo.helper.HelperContext;
public class TestSDOErronousSchemaReferences extends TestCase {
private HelperContext helperContext;
public TestSDOErronousSchemaReferences(String arg0) {
super(arg0);
this.helperContext = SDOUtil.createHelperContext(true);
}
public void testSDOErronousSchemaReferences() {
try {
String xsd = ?xml version=\1.0\
encoding=\ISO-8859-1\? schema
xmlns=\http://www.w3.org/2001/XMLSchema\;
xmlns:brugerinformation=\http://rep.oio.dk/brugerinformation.dk/xml/sch
emas/2007/01/01/\
xmlns:XKOM=\http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/\;
xmlns:DKCC=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\;
xmlns:DKCC2=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\;
targetNamespace=\http://rep.oio.dk/brugerinformation.dk/xml/schemas/200
7/01/01/\ elementFormDefault=\qualified\ xml:lang=\en\import
namespace=\http://rerp.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\;
schemaLocation=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
C_PostCodeIdentifier.xsd\/import
namespace=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\;
schemaLocation=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
C_DistrictName.xsd\/import
namespace=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\;
schemaLocation=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
C_StreetName.xsd\/import
namespace=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\;
schemaLocation=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
C_StreetBuildingIdentifier.xsd\/import
namespace=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/\;
schemaLocation=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/DKC
C_DistrictSubdivisionIdentifier.xsd\/import
namespace=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\;
schemaLocation=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
C_FloorIdentifier.xsd\/import
namespace=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/\;
schemaLocation=\http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/DKC
C_SuiteIdentifier.xsd\/annotationdocumentation//annotationeleme
nt name=\InstitutionAddress\
type=\brugerinformation:InstitutionAddressType\/complexType
name=\InstitutionAddressType\sequenceelement
name=\DaycareServiceName\ type=\string\/element
ref=\DKCC:StreetName\/element
ref=\DKCC2:StreetBuildingIdentifier\/element
ref=\DKCC2:FloorIdentifier\ minOccurs=\0\/element
ref=\DKCC2:SuiteIdentifier\ minOccurs=\0\/element
ref=\DKCC:PostCodeIdentifier\/element
ref=\DKCC:DistrictName\/element
ref=\DKCC:DistrictSubdivisionIdentifier\/element
name=\InstitutionPhonenrText\ type=\string\/element
name=\EmailaddText\ type=\string\/element name=\WeblinkText\
type=\string\//sequence/complexType/schema;
String root = InstitutionAddress;
String namespace =
http://rep.oio.dk/brugerinformation.dk/xml/schemas/2007/01/01/;;
System.out.println(First define with erronous
reference);
try {
test(xsd, root, namespace);
} catch (IllegalArgumentException e) {
e.printStackTrace();
}
System.out.println(\nSecond define just dummy
valid schema);
xsd = ?xml version=\1.0\
encoding=\ISO-8859-1\? schema
xmlns=\http://www.w3.org/2001/XMLSchema\;
xmlns:brugerinformation=\http://rep.oio.dk/brugerinformation.dk/xml/sch
emas/2007/01/01
RE: Root property that is not containment
The type needed as param for SDAOUtil.createDataTypeWrapper() is the simple type you want to set (testns#TestType in your example below). You can get it using typeHelper.getType(testns, TestType). SDOUtil.createDataTypeWrapper() will create a DataObject that wraps the requested data type value. SimpleAnyTypeDataObjectImpl is the Tuscany implementation class of the wrapper object. Frank. Christian Landbo Frederiksen [EMAIL PROTECTED] wrote on 04/03/2007 08:43:01 AM: Hi I know this thread is OLD, but I have been forced to look at this again (I thought I could ignore simple typed roots). I hope some of you can remember when you read it again :) My question is: how do you create the type needed as param for the SDOUtil.createDataTypeWrapper() method. I have seen the getXSDSDOType method but how do I find out what the simple type is, that is defined. I tried to do a load and it just resulted in a SimpleAnyTypeDataObjectImpl. Have you got any axamples using SDOUtil.createDataTypeWrapper()? /Chr -Original Message- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: 30. januar 2007 02:12 To: tuscany-user@ws.apache.org Subject: Re: Root property that is not containment Hi Cristian, To create a document with a root element that is a simple type (DataType as opposed to DataObject) you need a wrapper DataObject. You can call SDOUtil.createDataTypeWrapper() to get one. Frank. Christian Landbo Frederiksen [EMAIL PROTECTED] wrote on 01/29/2007 05:27:08 PM: Hi I have just started using this SDO-thing and I am very excited about it. I am using it to analyse xml-schemas and to generate and accept data for the given schemas. I have run into something (again). Lets say I am given a simple schema such as this: ?xml version=1.0 encoding=utf-8? schema xmlns:test=testns xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=testns element name=Test type=test:TestType/ simpleType name=TestType restriction base=decimal minInclusive value=0/ maxInclusive value=13/ /restriction /simpleType /schema When analysing this I cannot generate a DataObject for the Test-property because it is not a containment property. So I figured I could just use the 'DocumentRoot' DataObject, but this gives me XML like this, which is not valid: ?xml version=1.0 encoding=ASCII? _20:DocumentRoot xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:_20=testns xsi:type=_20_20:Test1/_20:Test/_20:DocumentRoot But what I wanted was something valid like this : ?xml version=1.0 encoding=UTF-8? Test xmlns=testns xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;3.1415926535897932 384626433832795/Test Am I missing something? What would be an appropiate way to deal with root-properties that are not containment properties? /Chr - 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] - 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]
Re: Root property that is not containment
The SDO spec says that xsd:double maps to the SDO type commonj.sdo#Double so you get it using typeHelper.getType(commonj.sdo, Double). Frank. Christian Landbo Frederiksen [EMAIL PROTECTED] wrote on 04/03/2007 04:46:13 PM: Ok great, but what if schema is as simple as this: ?xml version=1.0 encoding=utf-8? schema xmlns:test=testns xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=testns element name=Test type=double/ /schema /Chr -Original Message- The type needed as param for SDAOUtil.createDataTypeWrapper() is the simple type you want to set (testns#TestType in your example below). You can get it using typeHelper.getType(testns, TestType). SDOUtil.createDataTypeWrapper() will create a DataObject that wraps the requested data type value. SimpleAnyTypeDataObjectImpl is the Tuscany implementation class of the wrapper object. Frank. -Original Message- From: Christian Landbo Frederiksen Sent: 3. april 2007 14:43 To: 'tuscany-user@ws.apache.org' Subject: RE: Root property that is not containment Hi I know this thread is OLD, but I have been forced to look at this again (I thought I could ignore simple typed roots). I hope some of you can remember when you read it again :) My question is: how do you create the type needed as param for the SDOUtil.createDataTypeWrapper() method. I have seen the getXSDSDOType method but how do I find out what the simple type is, that is defined. I tried to do a load and it just resulted in a SimpleAnyTypeDataObjectImpl. Have you got any axamples using SDOUtil.createDataTypeWrapper()? /Chr -Original Message- From: Frank Budinsky [mailto:[EMAIL PROTECTED] Sent: 30. januar 2007 02:12 To: tuscany-user@ws.apache.org Subject: Re: Root property that is not containment Hi Cristian, To create a document with a root element that is a simple type (DataType as opposed to DataObject) you need a wrapper DataObject. You can call SDOUtil.createDataTypeWrapper() to get one. Frank. Christian Landbo Frederiksen [EMAIL PROTECTED] wrote on 01/29/2007 05:27:08 PM: Hi I have just started using this SDO-thing and I am very excited about it. I am using it to analyse xml-schemas and to generate and accept data for the given schemas. I have run into something (again). Lets say I am given a simple schema such as this: ?xml version=1.0 encoding=utf-8? schema xmlns:test=testns xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=testns element name=Test type=test:TestType/ simpleType name=TestType restriction base=decimal minInclusive value=0/ maxInclusive value=13/ /restriction /simpleType /schema When analysing this I cannot generate a DataObject for the Test-property because it is not a containment property. So I figured I could just use the 'DocumentRoot' DataObject, but this gives me XML like this, which is not valid: ?xml version=1.0 encoding=ASCII? _20:DocumentRoot xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:_20=testns xsi:type=_20_20:Test1/_20:Test/_20:DocumentRoot But what I wanted was something valid like this : ?xml version=1.0 encoding=UTF-8? Test xmlns=testns xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;3.1415926535897932 384626433832795/Test Am I missing something? What would be an appropiate way to deal with root-properties that are not containment properties? /Chr - 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] - 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]
Re: Problem deserializing element with attribute and xsi:nil=true
It sounds like a bug. Are you saying that get(intRange) is not null, but get(min) on the intRange is 0 (unset)? Frank Ron Gavlin [EMAIL PROTECTED] wrote on 04/04/2007 05:14:10 PM: Greetings, I have the following global element in a schema: xsd:element name=query xsd:complexType xsd:sequence xsd:element name=intRange type=IntegerRange nillable=true/ /xsd:sequence /xsd:complexType /xsd:element xsd:complexType name=IntegerRange xsd:attribute name=min type=xsd:integer / xsd:attribute name=max type=xsd:integer / /xsd:complexType When I use Tuscany SDO to deserialize the instance document below, the intRange min property does not appear to be set. Is this expected behavior or a bug? - Ron query intRange min=1 xsi:nil=true/ /query - 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]
Re: xsd:any problem
Hi Ashish, I'm not sure what you tried, but something like this should work: body.setDataObject(typeHelper.getOpenContentProperty(the target namespace???, ServiceInput), value); Frank. Ashish Panchal [EMAIL PROTECTED] wrote on 04/11/2007 12:00:50 PM: Hi, Iam trying to create a dataobject of xsd which has one of the element as xsd:any type. Sample is - xsd:element name=ServiceInput type=ServiceInputType/ xsd:complexType name=ServiceInputType xsd:sequence xsd:element minOccurs=0 ref=header/ xsd:element minOccurs=0 ref=body/ /xsd:sequence /xsd:complexType xsd:element name=body xsd:complexType xsd:sequence xsd:any maxOccurs=1 minOccurs=1 processContents=lax/ /xsd:sequence /xsd:complexType /xsd:element The xsd:any is used to allow different xml under the 'body' element, as the incoming xml structure is not fixed. Data object for this xsd is created, but Iam not able to set the dataobject of the variable xml structure under the 'body' element. I would appreciate any help. Thanks Ashish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java RC3: SDOGenerator generated code
Hi Daniel, I think you may be running into this known issue: https://issues.apache.org/jira/browse/TUSCANY-1143 If you have additional information that you can append to the JIRA that would be great. Any help fixing it would be even better :-) Thanks, Frank. Daniel Peter [EMAIL PROTECTED] wrote on 05/02/2007 11:22:46 AM: Hi all, I tried to migrate an M2 based project to M3 RC3, and ran into the following problem, regarding the code generated by the SDOGenerator: The initializeMetaData() method in a generated FactoryImpl class has this piece of code: ? // Obtain other dependent packages SdtFactoryImpl theSdtPackageImpl_1 = (SdtFactoryImpl)FactoryBase. getStaticFactory(SdtFactoryImpl.NAMESPACE_URI); ... // Add supertypes to types addSuperType(myClassType, mySuperClassType); ? But the variable mySuperClassType cannot be resolved at this point, it is defined in another package. After I changed the code as follows, it worked fine: addSuperType(myClassType, theSdtPackageImpl_1.getMySuperClass()); Another thing I noticed in the init() method of the FactoryImpl class: ... // Initialize simple dependencies SDOUtil.registerStaticTypes(SdtFactory.class); ? Is the usage of the SDOUtil.registerStaticTypes(...) method still wanted here? Thanks, Daniel. __ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xsd:any problem
Hi Chris,
The problem is this line of code:
person.setDataObject(address:Address, address);
SDO doesn't support qualified names in string (path) get/set methods.
That's why it ignores the address: prefix, and simply demand-creates
another Address property (PersonType:address).
To accomplish what you want, you can explicitly locate the address:Address
property like this:
Property addressProperty =
xsdHelper.getGlobalProperty(http://www.example.org/Address;, Address,
true);
Then you can set it like this:
person.setDataObject(addressProperty, address);
Frank.
[EMAIL PROTECTED] wrote on 05/06/2007 04:08:33 PM:
Hi Frank (or anyone else that may be able to help),
I have a related question to Ashish's. I have the following two schemas:
?xml version=1.0 encoding=UTF-8?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.org/Person;
xmlns:person=http://www.example.org/Person;
elementFormDefault=qualified
xsd:element name=Person type=person:PersonType/xsd:element
xsd:complexType name=PersonType
xsd:sequence
xsd:element name=Name type=xsd:string/xsd:element
xsd:element name=Age type=xsd:string/xsd:element
xsd:any namespace=##other processContents=lax
minOccurs=0
maxOccurs=unbounded/
/xsd:sequence
/xsd:complexType
/xsd:schema
?xml version=1.0 encoding=UTF-8?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.org/Address;
xmlns:address=http://www.example.org/Address;
elementFormDefault=qualified
xsd:element name=Address
type=address:AddressType/xsd:element
xsd:complexType name=AddressType
xsd:sequence
xsd:element name=Street type=xsd:string/xsd:element
xsd:element name=City type=xsd:string/xsd:element
xsd:element name=Zip type=xsd:string/xsd:element
/xsd:sequence
/xsd:complexType
/xsd:schema
I use the following code to generate my XML:
public static void main(String[] args) throws Exception
{
HelperContext context = SDOUtil.createHelperContext();
context.getXSDHelper().define(new
FileInputStream(./Person.xsd), (new
File(./Base.xsd)).toURI().toString());
context.getXSDHelper().define(new
FileInputStream(./Address.xsd), (new
File(./Additional.xsd)).toURI().toString());
DataObject person =
context.getDataFactory().create(http://www.example.org/Person;,
PersonType);
DataObject address =
context.getDataFactory().create(http://www.example.org/Address;,
AddressType);
person.set(Name, Bart);
person.set(Age, 10);
address.set(Street, 123 Fake St.);
address.set(City, Springfield);
address.set(Zip, 46392);
person.setDataObject(address:Address, address);
context.getXMLHelper().save(person,
http://www.example.org/Person;, Person, System.out);
}
This gives the following XML:
?xml version=1.0 encoding=ASCII?
person:Person
xmlns:PersonType=http://www.example.org/Person/PersonType;
xmlns:address=http://www.example.org/Address;
xmlns:person=http://www.example.org/Person;
person:NameBart/person:Name
person:Age10/person:Age
PersonType:Address
address:Street123 Fake St./address:Street
address:CitySpringfield/address:City
address:Zip46392/address:Zip
/PersonType:Address
/person:Person
My concern is the PersonType:Address element. I'd like that to be
address:Address instead. Am I doing something wrong in my schema
definitions and/or code?
Thanks for any help you can provide,
-Chris
On 4/16/07, Frank Budinsky [EMAIL PROTECTED] wrote:
Ashish,
I implemented the on-the-fly property creation support over the
weekend
(see https://issues.apache.org/jira/browse/TUSCANY-1211).
You should now be able to do what you asked:
body.setDataObject(anyType,DataObject);
Let me know how it works.
Thanks,
Frank
-
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]
Re: xsd:any problem
Sorry, I didn't notice that your xsd:any had maxOccurs 1:
xsd:any namespace=##other processContents=lax
minOccurs=0 maxOccurs=unbounded/
If it was maxOccurs=1 then you could do what I suggested.
Because it is many valued, however, you need to do this:
person.getList(addressProperty).add(address);
Notice that the isMany value of a global property is not statically known,
it depends on where it's being used.
Frank.
[EMAIL PROTECTED] wrote on 05/07/2007 09:54:04 AM:
Hi Frank,
I replaced my code with what you suggested:
Property addressProperty =
context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;,
Address,
true);
person.setDataObject(addressProperty, address);
The call to setDataObject() generates the following exception:
Exception in thread main java.lang.ClassCastException:
org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
at org.eclipse.emf.ecore.util.BasicFeatureMap.
set(BasicFeatureMap.java:1026)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eOpenSet(BasicEObjectImpl.java:723)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eSet(BasicEObjectImpl.java:658)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:142)
at org.apache.tuscany.sdo.util.DataObjectUtil.
setDataObject(DataObjectUtil.java:122)
at org.apache.tuscany.sdo.impl.DataObjectImpl.
setDataObject(DataObjectImpl.java:1105)
at com.ibm.isd.mapper.impl.Test.main(Test.java:33)
Any Ideas? Thanks for your help this far,
-Chris
On 5/7/07, Frank Budinsky [EMAIL PROTECTED] wrote:
Hi Chris,
The problem is this line of code:
person.setDataObject(address:Address, address);
SDO doesn't support qualified names in string (path) get/set methods.
That's why it ignores the address: prefix, and simply demand-creates
another Address property (PersonType:address).
To accomplish what you want, you can explicitly locate the
address:Address
property like this:
Property addressProperty =
xsdHelper.getGlobalProperty(http://www.example.org/Address;,
Address,
true);
Then you can set it like this:
person.setDataObject(addressProperty, address);
Frank.
[EMAIL PROTECTED] wrote on 05/06/2007 04:08:33 PM:
Hi Frank (or anyone else that may be able to help),
I have a related question to Ashish's. I have the following two
schemas:
?xml version=1.0 encoding=UTF-8?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.org/Person;
xmlns:person=http://www.example.org/Person;
elementFormDefault=qualified
xsd:element name=Person
type=person:PersonType/xsd:element
xsd:complexType name=PersonType
xsd:sequence
xsd:element name=Name type=xsd:string/xsd:element
xsd:element name=Age type=xsd:string/xsd:element
xsd:any namespace=##other processContents=lax
minOccurs=0
maxOccurs=unbounded/
/xsd:sequence
/xsd:complexType
/xsd:schema
?xml version=1.0 encoding=UTF-8?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://www.example.org/Address;
xmlns:address=http://www.example.org/Address;
elementFormDefault=qualified
xsd:element name=Address
type=address:AddressType/xsd:element
xsd:complexType name=AddressType
xsd:sequence
xsd:element name=Street
type=xsd:string/xsd:element
xsd:element name=City type=xsd:string/xsd:element
xsd:element name=Zip type=xsd:string/xsd:element
/xsd:sequence
/xsd:complexType
/xsd:schema
I use the following code to generate my XML:
public static void main(String[] args) throws Exception
{
HelperContext context = SDOUtil.createHelperContext();
context.getXSDHelper().define(new
FileInputStream(./Person.xsd), (new
File(./Base.xsd)).toURI().toString());
context.getXSDHelper().define(new
FileInputStream(./Address.xsd), (new
File(./Additional.xsd)).toURI().toString());
DataObject person =
context.getDataFactory().create(http://www.example.org/Person;,
PersonType);
DataObject address =
context.getDataFactory().create(http://www.example.org/Address;,
AddressType);
person.set(Name, Bart);
person.set(Age, 10);
address.set(Street, 123 Fake St.);
address.set(City, Springfield);
address.set(Zip, 46392);
person.setDataObject(address:Address, address);
context.getXMLHelper().save(person,
http://www.example.org/Person;, Person, System.out);
}
This gives the following XML:
?xml version=1.0 encoding=ASCII?
person:Person
xmlns:PersonType=http://www.example.org/Person/PersonType;
xmlns:address=http://www.example.org/Address;
xmlns:person=http
Re: xsd:any problem
Assuming that the line numbers in your stack trace correspond to the EMF version (2.2.3) that I'm looking at, it looks to me like null is being passed into the getList() method. If so, I assume it's because this line returned null: Property addressProperty = context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;, Address, true); That is, it couldn't locate your global property. Frank [EMAIL PROTECTED] wrote on 05/07/2007 12:13:35 PM: Hi Frank, Thank you so much for your help so far, your example worked. I'm learning quite a bit. I thought that would help me with my real work, but I'm seeing a different error. My schema can be found here: http://www.oasis-open.org/committees/download.php/23876/CL1_Schema.zip and here: http://www.w3.org/2000/09/xmldsig I generate my classes using IBM's JDK 1.4.2 with the following commands: set javaExe=C:\ibmsdk1.4.2_sr4-1\bin\java set output=. set schemaLocation=..\schema\sdd-20070504_49 set sdo_cp=lib\org.eclipse.emf.codegen_2.2.2.v200702131851.jar; lib\org.eclipse.emf.codegen.ecore_2.2.2.v200702131851.jar;lib\org. eclipse.emf.common_2.2.1.v200702131851.jar;lib\org.eclipse.emf. ecore_2.2.2.v200702131851.jar;lib\org.eclipse.emf.ecore.change_2.2. 1.v200702131851.jar;lib\org.eclipse.emf.ecore.xmi_2.2.2. v200702131851.jar;lib\sdo-api-r2.1-1.0-incubating-SNAPSHOT.jar; lib\tuscany-sdo-impl-1.0-incubating-SNAPSHOT.jar;lib\tuscany-sdo- tools-1.0-incubating-SNAPSHOT.jar;lib\org.eclipse.xsd_2.2.2.v200702131851.jar set options=-cp %sdo_cp% org.apache.tuscany.sdo.generate.XSD2JavaGenerator -arrayAccessors -targetDirectory %output% %javaExe% %options% %schemaLocation%\wd-sdd-common-1.0.xsd %javaExe% %options% %schemaLocation%\wd-sdd-deploymentDescriptor-1.0.xsd %javaExe% %options% %schemaLocation%\wd-sdd-packageDescriptor-1.0.xsd %javaExe% %options% %schemaLocation%\xmldsig-core-schema.xsd I've built the Tuscany SDO libraries from the 4/27 code in subversion with IBM's 1.4.2 JDK. Ok, with that out of the way, here is the problem I'm seeing: I have the following code: HelperContext context = SDOUtil.createHelperContext(); context.getXSDHelper().define(new FileInputStream(./wd-sdd-common-1.0.xsd), (new File(./wd-sdd-common-1.0.xsd)).toURI().toString()); context.getXSDHelper().define(new FileInputStream(./wd-sdd-deploymentDescriptor-1.0.xsd), (new File(./wd-sdd-deploymentDescriptor-1.0.xsd)).toURI().toString()); context.getXSDHelper().define(new FileInputStream(./xmldsig-core-schema.xsd), (new File(./xmldsig-core-schema.xsd)).toURI().toString()); PackageDescriptorType pd = DescriptorFactory.INSTANCE.createPackageDescriptorType(); PackageIdentityType identity = DescriptorFactory.INSTANCE.createPackageIdentityType(); context.getXSDHelper().define(new FileInputStream(./Address.xsd), (new File(./Address.xsd)).toURI().toString()); DataObject address = context.getDataFactory().create(http://www.example.org/Address;, AddressType); address.set(Street, 123 Fake St.); address.set(City, Springfield); address.set(Zip, 46392); Property addressProperty = context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;, Address, true); ((DataObject) identity).getList(addressProperty).add(address); context.getXMLHelper().save((DataObject) pd, urn:oasis:names:tc:SDD:1:0:packageDescriptor, PackageDescriptor, System.out); Similar to the other example, though now I'm initializing it using the statically generated classes. The call to getList() is throwing the following exception: Exception in thread main java.lang.NullPointerException at org.eclipse.emf.ecore.impl.BasicEObjectImpl. eOpenGet(BasicEObjectImpl.java:645) at org.eclipse.emf.ecore.impl.BasicEObjectImpl. eGet(BasicEObjectImpl.java(Compiled Code)) at org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:132) at org.apache.tuscany.sdo.util.DataObjectUtil. getList(DataObjectUtil.java:172) at org.apache.tuscany.sdo.impl.DataObjectImpl. getList(DataObjectImpl.java:995) at com.ibm.isd.mapper.impl.Test.anyTest_Static_PD(Test.java:116) at com.ibm.isd.mapper.impl.Test.main(Test.java:125) Thanks in advance for any pointers you can give, -Chris On 5/7/07, Frank Budinsky [EMAIL PROTECTED] wrote: Sorry, I didn't notice that your xsd:any had maxOccurs 1: xsd:any namespace=##other processContents=lax minOccurs=0 maxOccurs=unbounded/ If it was maxOccurs=1 then you could do what I suggested. Because it is many valued, however, you need to do this: person.getList(addressProperty).add(address); Notice that the isMany value of a global property is not statically known, it depends on where it's being used. Frank. [EMAIL PROTECTED] wrote on 05/07/2007 09:54:04 AM: Hi Frank, I replaced
Re: xsd:any problem
Hi Chris, Can you confirm that the cross-package inheritance is the problem by creating a similar subtype in the same package and see if it works? It should be pretty simple to fix this generator problem, but it would be helpful if you could provide a simple test case for us. Adding open content to an object is an intrinsically dynamic task and should be done using the dynamic API, even if the type is static. In other words, ask you suggested, this is the way to do it and it should work if there are no bugs: ((DataObject) identity).getList(addressProperty).add(address); Thanks, Frank. [EMAIL PROTECTED] wrote on 05/07/2007 04:44:01 PM: Hi Frank, I think I've tracked this problem down to an issue with static class generation. The common schema contains the any element in the identity element. The packageIdentity element in the packageDescriptor schema extends the identity element. Some things aren't quite right in the class generation with respect to that. I wrote a note to the dev mailing list explaining some of my issues. Seems this is a new issue related to my other issue. I'll update my note with my new findings. On a side note, adding content to the any element works when accessing the dynamic methods. Is there a way to take my instance of my statically generated class and use the dynamic methods for this set, and then go back to editing using the statically generated objects? Casting to DataObject doesn't seem to work: ((DataObject) identity).getList(addressProperty).add(address); Thanks, -Chris On 5/7/07, Frank Budinsky [EMAIL PROTECTED] wrote: Assuming that the line numbers in your stack trace correspond to the EMF version (2.2.3) that I'm looking at, it looks to me like null is being passed into the getList() method. If so, I assume it's because this line returned null: Property addressProperty = context.getXSDHelper().getGlobalProperty(http://www.example.org/Address;, Address, true); That is, it couldn't locate your global property. Frank [EMAIL PROTECTED] wrote on 05/07/2007 12:13:35 PM: Hi Frank, Thank you so much for your help so far, your example worked. I'm learning quite a bit. I thought that would help me with my real work, but I'm seeing a different error. My schema can be found here: http://www.oasis-open.org/committees/download.php/23876/CL1_Schema.zip and here: http://www.w3.org/2000/09/xmldsig I generate my classes using IBM's JDK 1.4.2 with the following commands: set javaExe=C:\ibmsdk1.4.2_sr4-1\bin\java set output=. set schemaLocation=..\schema\sdd-20070504_49 set sdo_cp=lib\org.eclipse.emf.codegen_2.2.2.v200702131851.jar; lib\org.eclipse.emf.codegen.ecore_2.2.2.v200702131851.jar;lib\org. eclipse.emf.common_2.2.1.v200702131851.jar;lib\org.eclipse.emf. ecore_2.2.2.v200702131851.jar;lib\org.eclipse.emf.ecore.change_2.2. 1.v200702131851.jar;lib\org.eclipse.emf.ecore.xmi_2.2.2. v200702131851.jar;lib\sdo-api-r2.1-1.0-incubating-SNAPSHOT.jar; lib\tuscany-sdo-impl-1.0-incubating-SNAPSHOT.jar;lib\tuscany-sdo- tools-1.0-incubating-SNAPSHOT.jar;lib\org.eclipse.xsd_2.2.2. v200702131851.jar set options=-cp %sdo_cp% org.apache.tuscany.sdo.generate.XSD2JavaGenerator -arrayAccessors -targetDirectory %output% %javaExe% %options% %schemaLocation%\wd-sdd-common-1.0.xsd %javaExe% %options% %schemaLocation%\wd-sdd-deploymentDescriptor-1.0.xsd %javaExe% %options% %schemaLocation%\wd-sdd-packageDescriptor-1.0.xsd %javaExe% %options% %schemaLocation%\xmldsig-core-schema.xsd I've built the Tuscany SDO libraries from the 4/27 code in subversion with IBM's 1.4.2 JDK. Ok, with that out of the way, here is the problem I'm seeing: I have the following code: HelperContext context = SDOUtil.createHelperContext(); context.getXSDHelper().define(new FileInputStream(./wd-sdd-common-1.0.xsd), (new File(./wd-sdd-common-1.0.xsd)).toURI().toString()); context.getXSDHelper().define(new FileInputStream(./wd-sdd-deploymentDescriptor-1.0.xsd), (new File(./wd-sdd-deploymentDescriptor-1.0.xsd)).toURI().toString()); context.getXSDHelper().define(new FileInputStream(./xmldsig-core-schema.xsd), (new File(./xmldsig-core-schema.xsd)).toURI().toString()); PackageDescriptorType pd = DescriptorFactory.INSTANCE.createPackageDescriptorType(); PackageIdentityType identity = DescriptorFactory.INSTANCE.createPackageIdentityType(); context.getXSDHelper().define(new FileInputStream(./Address.xsd), (new File(./Address.xsd)).toURI().toString()); DataObject address = context.getDataFactory().create(http://www.example.org/Address;, AddressType); address.set(Street, 123 Fake St.); address.set(City, Springfield); address.set(Zip, 46392
Re: SDO generator: equals and hashcode
Hi, No there isn't. The SDO spec says this in Section 3.1.12: A Java implementation of DataObject must not override the methods defined in java.lang.Object except for toString(). Frank. Daniel Peter [EMAIL PROTECTED] wrote on 05/11/2007 05:21:23 AM: Hi all, I see that the EqualityHelper provides the logic for determining the equality of SDOs. Is there a way to make the generator produce 'equals' and 'hashcode' methods in the generated SDO classes? Thanks, Daniel. __ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever - 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]
Clean up and restructure packages in SDO/Java porject
Hi, I'd like to start better organizing the interfaces and classes in the SDO Java project. Currently, there is no clean separation between client API vs. implementation (internal) classes. There's also no separation between the EMF-dependent and independent parts of the RT. I believe most of you know that we've been recommending clients stick to standard SDO APIs (from the spec) and for anything else use class SDOUtil, which is where we put all the required extensions that people have requested. One other interface, XMLStreamHelper (for working with StAX streams) is the only other interface in Tuscany that clients are expected to use directly. So, if you are only using standard SDO APIs, SDOUtil, and XMLStreamHelper, you should be unaffected for now, because we will keep deprecated versions of SDOUtil and XMLStreamHelper around for a while, but we would like to move them to a better package and have clients gradually move to the new ones. Here is the concrete proposal: package org.apache.tuscany.sdo.api (all client API will be under this package) SDOUtil (new one) XMLStreamHelper (new one) other new things ... package org.apache.tuscany.sdo.rtemf (EMF-based runtime implementation classes) subset of existing classes (most of them) that have EMF dependencies (these are existing packages just moved down one level, e.g., org.apache.tuscany.sdo.helper - org.apache.sdo.tuscany.sdo.rtemf.helper) package org.apache.tuscany.sdo.rtlib (common runtime implementation classes) subset of existing classes that have no EMF dependencies package org.apache.tuscany.util (deprecated) SDOUtil (deprecated - clients should switch to org.apache.tuscany.sdo.api.SDOUtil) package org.apache.tuscany.helper (deprecated) XMLStreamHelper (deprecated - clients should switch to org.apache.tuscany.sdo.api.XMLStreamHelper) Please let me know if you have any comments or concerns. Also please speak up if anybody has other classes that they would like us to keep deprecated versions of, to give you time to move. Thanks, Frank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sdo jars as eclipse plug-ins - problem solved - bad manifest
I don't know a lot about mvn or OSGi, but https://issues.apache.org/jira/browse/TUSCANY-1284 seems to imply that the MANIFEST.MF file can be generated from the POM. Do I have it right? Can anyone explain how it would all work? Where would the generated MANIFEST.MF file go? Thanks, Frank Bryan Hunt [EMAIL PROTECTED] wrote on 05/16/2007 01:57:20 PM: I've figured out the problem. The generated MANIFEST.MF contains an invalid bundle version. Changing Bundle-Version: 1.0.incubating.SNAPSHOT to Bundle-Version: 1.0.0 fixes the problem. Bryan On May 16, 2007, at 11:12 AM, Bryan Hunt wrote: As I currently understand things, the sdo jars are built such they can be used as OSGi bundles. Is my understanding correct? I tried the following with a fresh download of Eclipse 3.3 M7: cp ~/.m2/repository/commonj/sdo-api-r2.1/1.0-incubating-SNAPSHOT/ sdo-api-r2.1-1.0-incubating-SNAPSHOT.jar plugins/ ./eclipse -clean Eclipse fails to start with the following log file: !SESSION 2007-05-16 11:05:44.227 --- eclipse.buildId=I20070503-1400 java.version=1.5.0_07 java.vendor=Apple Computer, Inc. BootLoader constants: OS=macosx, ARCH=x86, WS=carbon, NL=en_US Framework arguments: -startup /Users/bhunt/Downloads/eclipse/ Eclipse.app/Contents/MacOS/../../../plugins/ org.eclipse.equinox.launcher_1.0.0.v20070502.jar Command-line arguments: -os macosx -ws carbon -arch x86 -startup / Users/bhunt/Downloads/eclipse/Eclipse.app/Contents/MacOS/../../../ plugins/org.eclipse.equinox.launcher_1.0.0.v20070502.jar -clean !ENTRY org.eclipse.update.configurator 4 0 2007-05-16 11:05:46.407 !MESSAGE !STACK 0 org.osgi.framework.BundleException: Exception in org.eclipse.update.internal.configurator.ConfigurationActivator.start( ) of bundle org.eclipse.update.configurator. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActiva tor(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start (BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker (BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume (AbstractBundle.java:350) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle (Framework.java:1118) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundl es(StartLevelManager.java:634) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL (StartLevelManager.java:508) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartL evel(StartLevelManager.java:282) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEve nt(StartLevelManager.java:468) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent (EventManager.java:195) at org.eclipse.osgi.framework.eventmgr.EventManager $EventThread.run(EventManager.java:297) Caused by: org.eclipse.core.runtime.CoreException: Cannot create configuration in file:/Users/bhunt/Downloads/eclipse/configuration/ at org.eclipse.update.internal.configurator.Utils.newCoreException (Utils.java:96) at org.eclipse.update.internal.configurator.ConfigurationActivator.initia lize(ConfigurationActivator.java:111) at org.eclipse.update.internal.configurator.ConfigurationActivator.start( ConfigurationActivator.java:69) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run (BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActiva tor(BundleContextImpl.java:993) ... 10 more Root exception: org.eclipse.core.runtime.CoreException: Cannot create configuration in file:/Users/bhunt/Downloads/eclipse/configuration/ at org.eclipse.update.internal.configurator.Utils.newCoreException (Utils.java:96) at org.eclipse.update.internal.configurator.ConfigurationActivator.initia lize(ConfigurationActivator.java:111) at org.eclipse.update.internal.configurator.ConfigurationActivator.start( ConfigurationActivator.java:69) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run (BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActiva tor(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start (BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker (BundleHost.java:346)
Re: Question about Changesummery for static Interfaces
Hi Steffen, What you're doing looks basically correct, so I think it should be working. What version of SDO are you using? I know that we fixed a bug in static (generated) SDO about 1 or 2 weeks ago, that may be related to this. Have you tried using the latest version from HEAD? If it still doesn't work, can you open a JIRA and provide us with a JUnit test and the necessary files to reproduce the problem? Thanks, Frank Steffen Glomb [EMAIL PROTECTED] wrote on 05/20/2007 12:08:56 PM: Hi people, I would appreciate if you could bring some light to my darkness regarding the following: After creating an XSD i generated corresponding interfaces and tried to see the Changesummary working. My assumption is the changesummary will give me changed Properties within the DataObjects of a DataGraph. So I did the following: 1. Created the datagraph + Created a rootObject + added another Object to the Root Object 2. stored and loaded the datagraph 3. turned on logging for the graph 4. changed a property of a DataObject from the graph 5. expected a changed dataobject in the summary, but did not get one. Am I missunderstanding how Changesummary works? Thanks for your help Steffen please see my code below DataGraph myGraph = SDOUtil.createDataGraph(); HelperContext hc = SDOUtil.createHelperContext(); // Creating a sample Datagraph, with a Container having a List of Vocables Type containerType = hc.getTypeHelper().getType(Container.class ); Container container = (Container) myGraph.createRootObject (containerType); Vocable vocable = SdoFactoryImpl.init().createVocable(); vocable.setVocableID(123123); container.getVocables().add(vocable); // Storing and loading it ByteArrayOutputStream outputStream = new ByteArrayOutputStream(); SDOUtil.saveDataGraph(myGraph, outputStream, null); System.out.println(new String(outputStream.toByteArray())); DataGraph loadGraph = SDOUtil.loadDataGraph(new ByteArrayInputStream(outputStream.toByteArray()), null); // turn on logging loadGraph.getChangeSummary().beginLogging(); // Making changes Container loadedContainer = (Container) loadGraph.getRootObject(); Vocable voc = (Vocable) loadedContainer.getVocables().get(0); voc.setVocableID(1312); loadGraph.getChangeSummary().endLogging(); List changedDataObjects = loadGraph.getChangeSummary ().getChangedDataObjects(); // prints out 0 :-( System.out.println(Size of changedObjects after changing a property: + changedDataObjects.size()); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Evolution of a specific SDO structure over time
Hi Daniel, My guess is that the underlying EMF XML loader already has options to support this. Someone (you? :-) just needs to figure out what options need to be exposed to SDO clients, or even turned on by default, to make it work in Tuscany. Frank. Daniel Peter [EMAIL PROTECTED] wrote on 05/24/2007 05:22:54 AM: Hi all, Assume there is a static generated SDO class, MySDO edition1. Then an additional optional element is added to the corresponding xsd, and thus the generated SDO class, MySDO edition2, gets an additional property. (At the time of the generation of MySDO edition1 it is not known, where in the structure additional optional elements might be added in the future.) Is there a way that MySDO edition2 can be used for Java serialization and the prior MySDO edition1 for deserialization, and vice versa? (Of course with the toleration of the potential loss of the information held in the additional optional properties.) Could the XML parser be configured to ignore unknown xml elements? Other options? Thanks, Daniel. __ Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever - 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]
Re: Evolution of a specific SDO structure over time
Hi Daniel, I guess it would be OK, but the downside of making it a default option (i.e., always do it) is that the SDO loader will then pretty much never fail - you'll be able to load any junk without getting any load errors. The other alternative is to expose the RECORD_UNKNOWN_FEATURE option as one supported by Tuscany SDO, so you can pass it to the XMLHelper.load() method when you want this behavior. Comments? What do others thing about this? Thanks Frank. Daniel Peter [EMAIL PROTECTED] wrote on 05/25/2007 10:12:29 AM: Hi Frank It works if the following line is added to the configureXMLResource method of class DataObjectUtil: resource.getDefaultLoadOptions().put(XMLResource. OPTION_RECORD_UNKNOWN_FEATURE,Boolean.TRUE); Could you add this? Regards, Daniel. __ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever - 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]
Re: Question about setting an element's value
Hi Chris, A complexType that extends a simpleType exposes the simple content as a property named value. So, you would set it like this: subCategory.set(value, myCategory); Frank [EMAIL PROTECTED] wrote on 05/25/2007 11:10:35 AM: Hi, I have the following schema: ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:ext=urn:Extension xmlns:xs=http://www.w3.org/2001/XMLSchema; targetNamespace=urn:Extension elementFormDefault=unqualified attributeFormDefault=unqualified version=1.0 xs:element name=Extension xs:complexType xs:sequence xs:element ref=ext:SubCategory minOccurs=0 maxOccurs=unbounded / /xs:sequence /xs:complexType /xs:element xs:element name=SubCategory xs:complexType xs:simpleContent xs:extension base=xs:string xs:attribute name=displayable type=xs:boolean use=optional / /xs:extension /xs:simpleContent /xs:complexType /xs:element /xs:schema And I'd like to create this xml: ?xml version=1.0 encoding=ASCII? ext:Extension xmlns:ext=urn:Extension ext:SubCategory displayable=truemyCategory/SubCategory /ext:Extension I'm having problems setting the value myCategory. In examples I've seen where the element does not contain an attribute, a simple set(SubCategory, myCategory) would work. It seems that I can't use that in this case. Here's my current code: HelperContext context = SDOUtil.createHelperContext(); InputStream in = new File(Extension.xsd).toURL().openStream(); context.getXSDHelper().define(in, null); DataObject extension = context.getDataFactory().create(urn:Extension, Extension); DataObject subCategory = extension.createDataObject(SubCategory); subCategory.setBoolean(displayable, true); extension.set(SubCategory, myCategory); context.getXMLHelper().save(extension, urn:Extension, Extension, System.out); When the set() method is called, i get the following exception: Exception in thread main java.lang.ClassCastException: java.lang.String at org.eclipse.emf.ecore.util.EcoreEList.set(EcoreEList.java:448) at org.eclipse.emf.ecore.impl. EStructuralFeatureImpl$InternalSettingDelegateMany. dynamicSet(EStructuralFeatureImpl.java:1647) at org.eclipse.emf.ecore.impl.BasicEObjectImpl. eDynamicSet(BasicEObjectImpl.java:709) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl. eDynamicSet(DynamicDataObjectImpl.java:159) at org.apache.tuscany.sdo.impl.DataObjectImpl. eSet(DataObjectImpl.java:1459) at org.eclipse.emf.ecore.impl.BasicEObjectImpl. eSet(BasicEObjectImpl.java:654) at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:142) at org.apache.tuscany.sdo.util.DataObjectUtil.set(DataObjectUtil.java:730) at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:225) at Test.valueTest(Test.java:186) at Test.main(Test.java:197) I've tried looking through the samples and test cases, but couldn't find a similar example. Any help in pointing me to the correct API would be appreciated. Thanks, -Chris - 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]
Re: AW: Evolution of a specific SDO structure over time
Good point Daniel. For Java deserialization we can do either or both of the following: 1) provide a way to set default options, e.g., SDOUtil.setDefaultXMLOptions(HelperContext, Object options). 2) provide a way to set the load options on the ObjectInputStream, e.g., SDOObjectInputStream.setXMLOptions(Object options). I think #1 is a general direction the SDO spec (SDO 3) wants to move, but #2 may be useful as well. Frank. Daniel Peter [EMAIL PROTECTED] wrote on 05/25/2007 04:15:15 PM: Hi Frank Exposing the RECORD_UNKNOWN_FEATURE option is sure a good idea. But I'm not sure if this is sufficient from the Java deserialization point of view. During Java deserialization the method readDataObject in the class HelperProviderImpl.ResolvableImpl calls the XMLHelper.load() method (currently without passing any options). There would be a mechanism needed, that allows to specify options which would then be later picked up by readDataObject during Java deserialization. What do you think? Thanks, Daniel. - Ursprüngliche Mail Von: Frank Budinsky [EMAIL PROTECTED] An: tuscany-user@ws.apache.org Gesendet: Freitag, den 25. Mai 2007, 16:30:52 Uhr Betreff: Re: Evolution of a specific SDO structure over time Hi Daniel, I guess it would be OK, but the downside of making it a default option (i.e., always do it) is that the SDO loader will then pretty much never fail - you'll be able to load any junk without getting any load errors. The other alternative is to expose the RECORD_UNKNOWN_FEATURE option as one supported by Tuscany SDO, so you can pass it to the XMLHelper.load() method when you want this behavior. Comments? What do others thing about this? Thanks Frank. Daniel Peter [EMAIL PROTECTED] wrote on 05/25/2007 10:12:29 AM: Hi Frank It works if the following line is added to the configureXMLResource method of class DataObjectUtil: resource.getDefaultLoadOptions().put(XMLResource. OPTION_RECORD_UNKNOWN_FEATURE,Boolean.TRUE); Could you add this? Regards, Daniel. __ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever - 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] __ Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error with simple example
One thing that's certainly wrong is Person[0] because an XPath index must be = 1. See section 12 of the SDO spec: http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1 Note that the code that you said returned what you want is using a property number (i.e., 0): List l = (List)root.getList(0); To see what the name of this property (number 0) is you can call: ((Property)root.getType().getProperties().get(0)).getName(); Whatever name that returns is the name of the property you should be able to use in the getDataObject() call: Person or PERSON or whatever, in your example. I'd suggest looking at the SDO spec, or some of the examples, to get a better understanding of how SDO works. Frank. António Mota [EMAIL PROTECTED] wrote on 06/04/2007 06:55:03 PM: One last note. If i test with List l = (List)root.getList(0); DataObject d = (DataObject)l.get(0); String name = d.get(0); returns the correct value, what i expected that DataObject cust = root.getDataObject(Person[0]); String name = cust.getString(LASTNAME); will return. Is the problem with the jTDS driver not returning Metadata? I don't know what to do now... 2007/6/4, António Mota [EMAIL PROTECTED]: Hi: It seems this error was a feature of MS sqlserver driver... I changed it to jTDS and it works now. BUT... now i hav a error on the following line (typical...) DataObject root = readCustomers.executeQuery(); --- now works DataObject cust = root.getDataObject(PERSON[0]); gives error!!! and the error is Class 'DataGraphRoot' does not have a feature named 'PERSON' If i try DataObject cust = root.getDataObject(0); gives org.eclipse.emf.ecore.util.EcoreEList$Dynamic cannot be cast to commonj.sdo.DataObject With DataObject cust = root.getDataObject(1); i got java.lang.IndexOutOfBoundsException So what's wrong now? For a simple test case this is working great :( Thanks all. 2007/6/4, António Mota [EMAIL PROTECTED]: Hi again: My first try with SDo wasn't encoraging. This very simple example das = DASImpl.FACTORY.createDAS(getConnection()); Command readCustomers = das.createCommand(select * from PERSON); DataObject root = readCustomers.executeQuery(); gives a error on this last line. The connection is ok because the same sql statement works using jdbc directly. The error is as follows: Exception in thread main java.lang.AbstractMethodError: com.microsoft.jdbc.sqlserver.SQLServerConnection. prepareStatement(Ljava/lang/String;I)Ljava/sql/PreparedStatement; at org.apache.tuscany.das.rdb.impl.ConnectionImpl. prepareStatement(ConnectionImpl.java:98) at org.apache.tuscany.das.rdb.impl.Statement. getPreparedStatement(Statement.java:199) at org.apache.tuscany.das.rdb.impl.Statement. executeQuery(Statement.java:53) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl. executeQuery(ReadCommandImpl.java:61) Help, anyone? -- Melhores cumprimentos / Best regards António Santos Mota -- Melhores cumprimentos / Best regards António Santos Mota -- Melhores cumprimentos / Best regards António Santos Mota - 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]
Re: [SDO Java DISCUSS] Contents of the next SDO release
This sounds good to me. I assume Christian's suggestion for additional SDOUtil methods, and Bert/Steffen's request for notification support, are two more candidates for 1.0. Christian and Bert/Steffen, are you planning to open JIRAs for those? I'm worried about how many things are really doable, given the target we have in mind for the release (next month). Are people going to help with these features by providing patches? If not, is delaying the release for another month or two acceptable? Personally, I'd like to stick with a July target for the release. If somebody wants a feature that we can't handle in time, they'll need to help implement it. Otherwise it slips to the next release. What do others think? By the way, that reminds me that we need someone to be release manager for this release. Any volunteers? If not, maybe Kelvin, you would be willing to do it, since you've already been doing lots of the prep work. Thanks, Frank [EMAIL PROTECTED] wrote on 06/11/2007 06:02:20 AM: Good suggestion Steffen. If you were able to open a Jira and dump into it any thoughts you may have had about the details of how you see this working that would be great. The more detail you put there, the more likely it is that someone who wants to get their hands dirty would be likely to pick it up; unless of course you have plans for doing it yourself. As an aside, it's always interesting to know the background to why a particular feature is important to someone, so if you felt like commenting on your scenarios that would benefit from this too, whether in the JIRA on or the list, that would be great. For my part here are the things that I'd like to see done ... - reorganisation of the build to create release distributions in line with the SCA release format - review and improvement of the samples and implementation of an alternative simple approach to running the samples that does not involve running a maven build - review and improvement of the website documentation In addition, some things I'd like to see being done, but I don't see as absolute prerequisites for a release are ... - creation of a further sdo sub-project that permits automated exercising of the sdo plugin and java generator - more test cases In terms of JIRA's, we currently have 3 marked for the specific release [1], rather then the generic Java-SDO-Next bucket [2] that is the placeholder for Jiras not assigned to a release. TUSCANY-1317 http://issues.apache.org/jira/browse/TUSCANY-1317, TUSCANY-1143 http://issues.apache.org/jira/browse/TUSCANY-1143 , TUSCANY-513 http://issues.apache.org/jira/browse/TUSCANY-513 The first is there because the originator marked it for the beta1, which it didn't make, but it looks well defined, so after the beta1 I changed the fix release to the 1.0 release, but I don't think I'll have the bandwidth to cover this. The second is there because I want it to be, and plan to tackle it. The third is there because the originator has provided a patch and I'm in the process of committing it. In the light of my priorities above, having taken a scan through [2] in addition to 1143, I plan to look at ... TUSCANY-1122TypeConversionTestCase fails for JDK 1.4.2 TUSCANY-1127ObtainingDataGraphFromXml, and maybe other samples, incorrectly accessing xsd:any content TUSCANY-1284Manifest version number in Java SDO Impl and Tools jars TUSCANY-257recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 and there are a few others I have my eye on, e.g. 303, if all the above goes well. Regards, Kelvin. [1] http://issues.apache.org/jira/secure/IssueNavigator.jspa? reset=truepid=12310210status=1status=3status=4component=12311542component=12310660component=12310973component=12310802fixfor=12312521sorter/field=issuekeysorter/order=DESC [2] http://issues.apache.org/jira/secure/IssueNavigator.jspa? reset=truepid=12310210status=1status=3status=4component=12310660component=12310973component=12310802fixfor=12312262sorter/field=issuekeysorter/order=DESC On 09/06/07, Steffen Glomb [EMAIL PROTECTED] wrote: i would like to see support for typesafe collections in the xsd2java generator. regards Steffen On 6/8/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd like to draw the communities attention to this issue again please. Thanks to David for responding with his requirements and with the fix for 1223. I have some thoughts that I'm structuring at the moment on what's important for a next release from my perspective that I'll post soon, but in general I'm just keen to get the good stuff that we have added recently out in a release that, as I said before from my perspective, warrants the title of 1.0. With the Summer holiday season coming up, I'd like to do this soon so that I can sun myself on a beach without that niggling feeling of things that
Re: DataObject against XSD validation
Hi Erich, SDO 2.1 did not add a validation API to SDO. What it did add, was the ability to access instanceProperties on metaobjects (Type and Property), so that one could write an SDO-level validator. See section 3.5.6 of the SDO spec: http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1 The 2.1 spec left it to an implementation to decide what, if any, XSD facets are made available as instanceProperties, so there really is no standard way to do validation in SDO 2.1. Validation, is however, one of the major features planned for SDO 3. In the meantime, we are considering adding an SDOUtil method to do this. In fact, Kelvin was just discussing this on another thread this morning: http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200706.mbox/[EMAIL PROTECTED] Any input you have on the topic, would be most welcome. Thanks, Frank. Erich Rueede [EMAIL PROTECTED] wrote on 06/12/2007 11:16:28 AM: Hi, I am referring to an earlier post about this topic last year. The answer was that spec level 2.1 will address the validation. Is there now a way to call a deferred validate method on a static SDO graph to find out whether it is valid against the constraints defined in the associated XML schema? Thanks Erich Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - 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]
Re: Databinding, dataobject - UI Component
Hi Bert, I think I'm following this at a high level, but need to see some code to understand the details - especially exactly what the client API for hooking up observers looks like. Is your code confidential, or could you send us a zip file with the code in it. If you can contribute it, I think that we may be able to do something similar in Tuscany. We probably won't need to have a separate ObservableDataObject class, though, because the underlying notification mechanism is already in place (to support ChangeSummary), so we just need to enable it and provide a way for clients to use it. By the way, I did ask one of the original authors of the SDO spec the question of why notification was initially left out of SDO, and the answer was simply because there were too many other issues that needed to be agreed on between the collaboration members, and in terms of priority, notification didn't make it high enough on the list. There was, however, interest in adding it in the future. Frank. [EMAIL PROTECTED] wrote on 06/14/2007 07:02:09 AM: I'll try to explain what we do. Our requirements - use data objects in a server side environment where there is no UI - use data objects tightly integrated in a swing-based UI Due to all kind of reasons beyond our control, client-side implementation classes have a different release cycle than our server side classes. As such it is very difficult to reuse the same classes both on client and server. Strangely, but true, this is especially the case for the classes inside our UI framework. We solved this issue by creating a core sdo module. This module provides an implementation of the SDO spec. On the server side we only use this core module. To allow for independent specialization for UI events, we implemented the DataObject interface in our core in such a way that most of the functionality is in a class called AbstractDataObject. An extension to this class basically has to provide an implementation for set(Property, Object) and get(Property). The core provides a simple implementation based on an array of objects (an alternative could be a Map). The UI extension provides an implementation based on our UI framework with a different implementation for the property setters and getters (typically such that UI events are delivered). The UI extension also defined an extenstion to DataObject (called ObservableDataObject) to allow (de)registration of event listeners on properties. The rest of the UI extension just provides a type-safe ObservableDataFactory. One issue we encountered was the representation of many-valued properties. Our UI doesn't want to represent lists of objects as instances of java.util.List but instead as some form of javax.swing.ListModel which (for legacy reasons) didn't and couldn't implement java.util.List. This was especially annoying because the core implementation (for instance for XMLhelper and serialization) of course needs to iterate over all values of a multi-valued property. We solved this by adding a getIterator(Property) method on our AbstractDataObject. A second implementation issue we encountered was related to the inheritance hierarchy. Our ObservableDataObject on the one hand needed functionality of DataObject and on the other hand for the UI it needed functionality of ICompositeObject (a concept defined in our UIFramework). Both interfaces have existing abstract implementations. As multiple inheritance is not allowed in Java, we couldn't have an implementation class inheriting the behaviour from both abstract implementations (although conceptually this should be possible because the two interfaces have nothing in common). So we ended up with either having to use a delegation pattern or to copy the source-code of on of our abstract implementations. I hope this makes it a bit more clear. Feel free to ask for more details. Bert Frank Budinsky [EMAIL PROTECTED] 12/06/2007 14:42 Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org cc Subject Re: Databinding, dataobject - UI Component Hi Bert (and Steffen), As far as adding notification support in Tuscany is concerned, it would not be very difficult, given the underlying EMF implementation. Tuscany uses the EMF notification framework to implement ChangeSummary, so it wouldn't be hard to provide a way to allow (UI) observers to also be attached. What we don't want is for users to use the underlying EMF EAdapter API directly, because EMF is considered an internal implementation detail which is subject to change. Unfortunately, since SDO does not provide a standard API for doing this, we will need to come up with something Tuscany-specific, but longer term we could try to push a design back into the SDO spec (version 3). So, I'd be very interested in any ideas you have, and to see how you've
Re: ClassCastException on getChangeSummary().beginLogging();
Hi Tom, Tuscany overrides the templates, and many of the other GenModel settings for it's code generation. If you look in class org.apache.tuscany.sdo.generate.JavaGenerator you'll see code like this: generator.getAdapterFactoryDescriptorRegistry().addDescriptor (GenModelPackage.eNS_URI, SDOGenModelGeneratorAdapterFactory. DESCRIPTOR); and this: genModel.setRootExtendsInterface(); genModel.setRootImplementsInterface(commonj.sdo.DataObject); genModel.setRootExtendsClass( org.apache.tuscany.sdo.impl.DataObjectImpl); genModel.setFeatureMapWrapperInterface(commonj.sdo.Sequence); genModel.setFeatureMapWrapperInternalInterface( org.apache.tuscany.sdo.util.BasicSequence); genModel.setFeatureMapWrapperClass( org.apache.tuscany.sdo.util.BasicSequence); genModel.setSuppressEMFTypes(true); genModel.setSuppressEMFMetaData(true); genModel.setSuppressEMFModelTags(true); genModel.setCanGenerate(true); //FIXME workaround java.lang.NoClassDefFoundError: org/eclipse/jdt/core/jdom/IDOMNode with 02162006 build genModel.setFacadeHelperClass(Hack); genModel.setForceOverwrite(true); ... etc ... I think you should be able set up the EMF generator (GUI) the same way, but I'd ask on the EMF newsgroup. If you can figure out how to do it and contribute something back to Tuscany, that would be really great. Thanks, Frank kelvin goodson [EMAIL PROTECTED] wrote on 06/25/2007 08:24:22 AM: Hi Tom, the only generator we have in good shape to generate Tuscany SDO classes is the XSD to Java generator. I think it would be a significant new feature to properly support what you are trying to do. You are correct in your understanding that you must arrange for a specialised factory to be in place to create your types, so that they are instances of Type rather than of EClass. Tuscany SDO itself has to do this in order to ensure that the SDOFactory is used to create SDO objects. Regards, Kelvin. On 25/06/07, Thomas Kuhn [EMAIL PROTECTED] wrote: Hi, I'm getting a ClassCastException (see below) when I try to do myDataObj.getChangeSummary().beginLogging(); I am use EMF to create the objects. I changed the .genmodel file to generate SDO objects (I changed the genmodel first to create SDO 1.0 objects. Subsequently, I modified the .genmodel file to generate code that uses the Tuscany classes). The generated interfaces extend DataObject and their implementations correctly extend DataObjectImpl. I think the problem lies in the generated Package file, where getMyDataObj() returns an EClass. If it would be of any help, I can provide the .genmodel file. Is it possible at all to generate SDO from an EMF model? Thanks in advance, Tom java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EClassImpl at org.apache.tuscany.sdo.impl.DataObjectImpl.getType(DataObjectImpl.java:192) at org.apache.tuscany.sdo.util.DataObjectUtil.getChangeSummary(DataObjectUtil.j ava:688) at org.apache.tuscany.sdo.impl.DataObjectImpl.getChangeSummary(DataObjectImpl.j ava:1314) Environment: EMF 2.2.0, SDO 2.1.0 incubating beta1 - 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]
Re: Problem defining Data with XSD
Hi Manuel, Your xsd has an error. The type of the TestItemType element needs to include the namespace: xsd:element name=TestItemType type=testns:TestItemType/ At some point, we really need to improve the error handling. Frank. [EMAIL PROTECTED] wrote on 06/25/2007 11:14:07 AM: Hi there, I have a xsd file that looks like this: --- xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:testns=http://www.test.com/; targetNamespace=http://www.test.com/; xsd:element name=TestItemType type=TestItemType/ xsd:complexType name=TestItemType xsd:sequence xsd:element name=testelement type=xsd:string/ /xsd:sequence /xsd:complexType /xsd:schema --- Based on that XSD I want to load a xml file that looks like this: --- ?xml version=1.0 encoding=UTF-8? po:TestItemType xmlns:po=http://www.test.com/; testelementThis is a Test!/testelement /po:TestItemType --- To load the data I first call XSDHelper.INSTANCE.define() for the xsd file and then XMLHelper.INSTANCE.load() for the xml file. But while loading the xml file I always get an exception: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature 'testelement' not found. (http:///temp.xml, 3, 15) I do not use any file called temp.xml at all. The files where the xsd and xml information are stored are calld test.xsd and test.xml. Does anyone have any Idea how to get rid of this error? Thanx in advance. Best Regards, Manuel - 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]
Frank Budinsky/Toronto/IBM is out of the office.
I will be out of the office starting 06/27/2007 and will not return until 07/09/2007. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A question on SDO 2.0
You should be able to cast the DataObject to the Computer interface. If you can't my guess is that you didn't register the metadata, by calling the generated Factory.register() method, before loading the XML. Frank. qi chi [EMAIL PROTECTED] wrote on 07/05/2007 05:25:58 AM: Dear all, We are using tuscany SDO implementation. There is a problem that we can not resolve. Would you please kindly give some hints. We hava schema ?xml version=1.0 encoding=UTF-8? schema targetNamespace=http://stf.ibm.com/Computer; elementFormDefault=qualified xmlns=http://www.w3.org/2001/XMLSchema; xmlns:tns=http://stf.ibm.com/Computer; complexType name=Computer sequence element name=type type=string/element element name=price type=string/element /sequence /complexType element name=computer type=tns:Computer/element /schema We use XSD2JavaGenerator and get a interface Computer and class ComputerImpl. How can we load a XML and get a ComputerImpl instance? Currently, we can only load a XML as a DataObject. And we can not find a way to cast the DataObject to the ComputerImpl Java Object. - 雅虎免费邮箱-3.5G容量，20M附件
Re: static DataObject with contained static DataGraph doesn't record changes in summary
Hi Kelvin and Erich, I just debugged through this, and it's definitely a bug in the change summary code. It's another one in the line of bugs we've been finding related to the change we made when we separated SDO user properties from the internal EMF ones. It's another example of where the wrong index (SDO property index) is being used when it should be the internal EMF feature index. I'll look at it a little more tomorrow to figure out what the cleanest fix is. Frank. Erich Rueede [EMAIL PROTECTED] 07/09/2007 08:45 AM Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org, [EMAIL PROTECTED] cc Subject Re: static DataObject with contained static DataGraph doesn't record changes in summary Hi Kelvin I did not get the exception you mentioned. I guess this might be due to different versions of the SDO/EMF implementation we are using. Regards, Erich --- kelvin goodson [EMAIL PROTECTED] wrote: Hi Erich, I'm looking at this but currently I am getting an exception generated here ... saveGraph(staticGraph); I'll investigate why this might be. Have you seen anything like this? I noticed I had to do some changes to your code to make it compile, which implies you are using some generator options. For completeness, can you let me know what generator options you are using. Regards, Kelvin. static graph ** Exception in thread main java.lang.IllegalStateException: The containment feature could not be located at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eContainmentFeature( BasicEObjectImpl.java:475) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eContainmentFeature( BasicEObjectImpl.java:439) at org.apache.tuscany.sdo.impl.DataObjectImpl.getContainmentProperty( DataObjectImpl.java:182) at org.apache.tuscany.sdo.util.resource.ChangeSummaryStreamSerializer.saveChangeSummary (ChangeSummaryStreamSerializer.java:609) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLSaveImpl.saveChangeSummary (SDOXMLResourceImpl.java:806) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLSaveImpl.saveDataTypeElementSingle (SDOXMLResourceImpl.java:816) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures( XMLSaveImpl.java:1370) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID( XMLSaveImpl.java:2462) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement( XMLSaveImpl.java:1036) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement( XMLSaveImpl.java:922) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLSaveImpl.saveElementFeatureMap (SDOXMLResourceImpl.java:844) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures( XMLSaveImpl.java:1355) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject( XMLSaveImpl.java:627) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java :552) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:233) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave( XMLResourceImpl.java:203) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save( ResourceImpl.java:993) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.save( XMLDocumentImpl.java:205) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.save( XMLDocumentImpl.java:159) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java :139) at org.apache.tuscany.sdo.helper.XMLHelperImpl.save(XMLHelperImpl.java :134) at t_user.erich_rueede.DgExtended.saveGraph(DgExtended.java:69) at t_user.erich_rueede.DgExtended.main(DgExtended.java:42) On 07/07/07, Erich Rueede [EMAIL PROTECTED] wrote: Hi Frank and Kelvin since I don't know how to make attachments work for the mailing list, here's a text copy of its content: The XSD: xsd:schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://abc.com/services; xmlns:tns=http://abc.com/services; xmlns:sdo=commonj.sdo xmlns:sdoJava=commonj.sdo/java xmlns:sdoXml=commonj.sdo/xml sdoJava:package=com.abc.services xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:import namespace=commonj.sdo schemaLocation=datagraph.xsd / xsd:complexType name=NestedType xsd:sequence xsd:element name=test1 type=xsd:string / xsd:element name=test2 type=xsd:string / /xsd:sequence /xsd:complexType xsd:complexType name=MyDataGraph complexContent extension base=sdo:BaseDataGraphType xsd:sequence xsd:element name=NestedType type=tns:NestedType / /xsd:sequence /extension /complexContent
Re: Problem with using DataGraph and XMLHelper
Hi Dean,
Normally, when you create a DataObject in a DataGraph, you serialize the
DataGraph using SDOUtil.saveDataGraph(), not XMLHelper.save(). Does that
work properly?
That said, you should also be able to serialize any DataObject using
XMLHelper.save(). If the object is in a container (e.g., the DataGraph in
your example) then when you call XMLHelper.save() it's supposed to
temporarily detach it from it's container, serialize it, and then reattach
it at the end. So, I would expect your second example to serialize just
like the first one. It looks to me like there may be a bug in the
detach/reattach code in this case. Any help tracking it down would be
appreciated.
Thanks,
Frank
Dean Povey [EMAIL PROTECTED] wrote on 07/09/2007 09:30:10 PM:
Hi All,
I am running across a problem using XMLHelper to generate XML from
arbitrary DataObjects. If I create a bare DataObject it seems to work
fine. If I use the same object contained in a DataDraph it falls in a
heap. I am using Tuscany SDO 1.0 Beta1.
Here is an example that illustrates the problem:
import java.io.IOException;
import org.apache.tuscany.sdo.util.SDOUtil;
import commonj.sdo.DataGraph;
import commonj.sdo.DataObject;
import commonj.sdo.Type;
import commonj.sdo.helper.DataFactory;
import commonj.sdo.helper.TypeHelper;
import commonj.sdo.helper.XMLHelper;
public class Example {
private static final String NSURI = http://example.com/;;
public static void main(String[] args) throws IOException {
// Create an arbitrary type
DataObject exampleType =
DataFactory.INSTANCE.create(commonj.sdo,
Type);
exampleType.set(uri, NSURI);
exampleType.set(name, example);
DataObject exampleProperty =
exampleType.createDataObject(property);
exampleProperty.set(name, property);
exampleProperty.set(type,
TypeHelper.INSTANCE.getType(commonj.sdo, String));
Type type = TypeHelper.INSTANCE.define(exampleType);
// Success
DataObject ok = DataFactory.INSTANCE.create(type);
ok.set(property, Helloworld);
XMLHelper.INSTANCE.save(ok, NSURI, example-ok,
System.out);
// Failure
System.out.println();
DataGraph dg = SDOUtil.createDataGraph();
DataObject fails = dg.createRootObject(type);
fails.set(property, Helloworld);
XMLHelper.INSTANCE.save(fails, NSURI, example-fail,
System.out);
}
}
This generates the output:
?xml version=1.0 encoding=ASCII?
example-ok xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://example.com/; xsi:type=example
property=Helloworld/
?xml version=1.0 encoding=ASCII?
example-fail xmlns=http://example.com/; href=root.xml#//
In the later case it has failed to correctly write out the XML.
Is there something I am missing or doing wrong here?
Dean.
-
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]
Re: XML save problem with static generated SDO classes
Thanks Daniel. It sounds like I may have broken something with my latest fix. That's what you get for rushing :-) I'll take a look and fix it, hopefully today. We really need some good static test cases. You guys seem to be touching on a lot of function that has been exposing bugs in the generator. Is there any chance that you could contribute a test case that tests all the things that you've run into, so we could retry it whenever we change the generator? We could then continue to build on it over time to test new things that turn up. Thanks, Frank Daniel Peter [EMAIL PROTECTED] 07/16/2007 10:26 AM Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org cc Subject Re: XML save problem with static generated SDO classes Hi Frank I built this morning from the SVN head (was at revision 556544) in order to get the latest fixes, and generated the classes based on that. Daniel. - Ursprüngliche Mail Von: Frank Budinsky [EMAIL PROTECTED] An: tuscany-user@ws.apache.org Gesendet: Montag, den 16. Juli 2007, 15:18:28 Uhr Betreff: Re: XML save problem with static generated SDO classes Hi Daniel, This seems like a very basic function that isn't working. What version of Tuscany are you using? I wonder if this has been broken, as a side effect of one of the recent generator changes? (we really need to get some static SDO regression tests into the build). Please note that you need to regenerate you classes with the latest version of the generator, before running them. Thanks, Frank. Daniel Peter [EMAIL PROTECTED] wrote on 07/16/2007 09:05:00 AM: I work with static generated SDO classes. When saving an object containing a list of nested objects to XML, the nested objects are not correctly saved to XML. It looks like the toString method is called for the objects in the nested list, insted of xml save. This is the sample output XML: namedept1/name Employees[EMAIL PROTECTED] (name: empl1)/Employees /Output This is the corresponding xsd I used: ?xml version=1.0 encoding=UTF-8? targetNamespace=http://xyz.com;; xmlns:tns=http://xyz.com;; xmlns:xsd=http://www.w3.org/2001/XMLSchema;; xsd:element name=department type=DepartmentType/ xsd:complexType name=DepartmentType xsd:sequence xsd:element name=name type=xsd:string / xsd:sequence xsd:element name=Employees type=EmployeeType maxOccurs=unbounded/xsd:element /xsd:sequence /xsd:sequence /xsd:complexType xsd:complexType name=EmployeeType xsd:sequence xsd:element name=name type=xsd:string / /xsd:sequence /xsd:complexType /xsd:schema This is the test java code I used: DepartmentType d = XyzFactory.INSTANCE.createDepartmentType(); d.setName(dept1); EmployeeType e = XyzFactory.INSTANCE.createEmployeeType(); e.setName(empl1); d.getEmployees().add(e); System.out.println(HelperProvider.getDefaultContext(). getXMLHelper().save((DataObject)d, null, Output)); Thanks, Daniel. __ Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Wissenswertes zum Thema PC, Zubehör oder Programme. BE A BETTER INTERNET-GURU! www.yahoo.de/clever - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML save problem with static generated SDO classes
Daniel, I just looked at it, and it turns out to be a bug in your XSD. You need to qualify references to types in the current schema. The line that says: xsd:element name=Employees type=EmployeeType needs to be changed to this: xsd:element name=Employees type=tns:EmployeeType The same problem is also on the global element declaration: xsd:element name=department type=DepartmentType/ It should be: xsd:element name=department type=tns:DepartmentType/ This is very common XSD error, that has been turning up a lot lately. Maybe we need to change the generator to throw an exception in this case. What it's currently doing is being tolerent of the error by mapping the unknown type to SDO type Object and continuing. Frank Frank Budinsky/Toronto/[EMAIL PROTECTED] wrote on 07/16/2007 11:12:33 AM: Thanks Daniel. It sounds like I may have broken something with my latest fix. That's what you get for rushing :-) I'll take a look and fix it, hopefully today. We really need some good static test cases. You guys seem to be touching on a lot of function that has been exposing bugs in the generator. Is there any chance that you could contribute a test case that tests all the things that you've run into, so we could retry it whenever we change the generator? We could then continue to build on it over time to test new things that turn up. Thanks, Frank Daniel Peter [EMAIL PROTECTED] 07/16/2007 10:26 AM Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org cc Subject Re: XML save problem with static generated SDO classes Hi Frank I built this morning from the SVN head (was at revision 556544) in order to get the latest fixes, and generated the classes based on that. Daniel. - Ursprüngliche Mail Von: Frank Budinsky [EMAIL PROTECTED] An: tuscany-user@ws.apache.org Gesendet: Montag, den 16. Juli 2007, 15:18:28 Uhr Betreff: Re: XML save problem with static generated SDO classes Hi Daniel, This seems like a very basic function that isn't working. What version of Tuscany are you using? I wonder if this has been broken, as a side effect of one of the recent generator changes? (we really need to get some static SDO regression tests into the build). Please note that you need to regenerate you classes with the latest version of the generator, before running them. Thanks, Frank. Daniel Peter [EMAIL PROTECTED] wrote on 07/16/2007 09:05:00 AM: I work with static generated SDO classes. When saving an object containing a list of nested objects to XML, the nested objects are not correctly saved to XML. It looks like the toString method is called for the objects in the nested list, insted of xml save. This is the sample output XML: namedept1/name Employees[EMAIL PROTECTED] (name: empl1)/Employees /Output This is the corresponding xsd I used: ?xml version=1.0 encoding=UTF-8? targetNamespace=http://xyz.com;; xmlns:tns=http://xyz.com;; xmlns:xsd=http://www.w3.org/2001/XMLSchema;; xsd:element name=department type=DepartmentType/ xsd:complexType name=DepartmentType xsd:sequence xsd:element name=name type=xsd:string / xsd:sequence xsd:element name=Employees type=EmployeeType maxOccurs=unbounded/xsd:element /xsd:sequence /xsd:sequence /xsd:complexType xsd:complexType name=EmployeeType xsd:sequence xsd:element name=name type=xsd:string / /xsd:sequence /xsd:complexType /xsd:schema This is the test java code I used: DepartmentType d = XyzFactory.INSTANCE.createDepartmentType(); d.setName(dept1); EmployeeType e = XyzFactory.INSTANCE.createEmployeeType(); e.setName(empl1); d.getEmployees().add(e); System.out.println(HelperProvider.getDefaultContext(). getXMLHelper().save((DataObject)d, null, Output)); Thanks, Daniel. __ Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Wissenswertes zum Thema PC, Zubehör oder Programme. BE A BETTER INTERNET-GURU! www.yahoo.de/clever - 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]
Re: How to add Property to an XSDHelper-defined Type
Since the properties start at 0, the extra property number should be equal
to INTERNAL_PROPERTY_COUNT. That looks right.
The StackOverflowException problem looks to me to be caused by the fact
that the generated methods like isSet(int) are expected to find the
property and only call super in the dynamic case. In your case, the
property isn't statically handled, so it eventually calls
DataObjectBase.eIsSet():
public boolean eIsSet(int featureID)
{
if (isDynamic())
{
return super.eIsSet(internalConvertIndex(featureID));
} else
{
return isSet(internalConvertIndex(featureID));
}
}
which will recursively call isSet() again because isDynamic() returns
false. Somehow the code needs to be changed so that the dynamic property
also causes it to go down the isDynamic() path.
Actually, this eIsSet() method looks fishy to me regardless. First, the
call to internalConvertIndex(featureID) for the call to super.eIsSet()
looks wrong to me. I think it should be just featureID. The super call is
expecting the internal (EMF) number, not the converted SDO number. Second,
even in the dynamic sublass case (which this is supposed to be handling, I
think that a client call to eIsSet() won't work, because it won't ever go
down the isSet() patch which handles the static properties (in the base
class(es)).
I think the isDynamic() part of this method should be removed and instead
there should be an implementation of isSet(int) (in ExtensibleDataObject
probably?) that handles the case of a property that is either in a dynamic
sublass or was dynamically added to a static type.
Frank.
Ron Gavlin [EMAIL PROTECTED] wrote on 07/26/2007 01:09:27 PM:
Frank,
This scenario appears to trigger a property-indexing problem. The
newly added property's EMF featureID of 18 equals the value of
MyTypeImpl.SDO_PROPERTY_COUNT and MyTypeImpl.
INTERNAL_PROPERTY_COUNT. This appears to cause an infinite loop. Any
ideas for working around this problem?
- Ron
- Original Message
From: Ron Gavlin [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 26, 2007 12:53:07 PM
Subject: Re: How to add Property to an XSDHelper-defined Type
Hi Frank,
The EMF Diagnostician validate() is generating a
StackOverflowException which may be exposing a bug in the Tuscany
SDO dynamic subclassing area. Here is the stack trace. Let me know
if anything jumps out at you. BTW, I am currently using Tuscany SDO
version R548343 and EMF 2.2.2. I plan upgrade to the final 1.0
release when it is ready.
- Ron
java.lang.StackOverflowError
at mypackage.impl.MyFactoryImpl.getMyType(MyFactoryImpl.java:1135)
at mypackage.impl.MyTypeImpl.getStaticType(MyTypeImpl.java:821)
at org.apache.tuscany.sdo.impl.DataObjectBase.
eStaticClass(DataObjectBase.java:378)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eClass(ExtensibleDataObjectImpl.java:118)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eDerivedStructuralFeatureID(ExtensibleDataObjectImlp.java:87)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:815)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
- Original Message
From: Ron Gavlin [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 26, 2007 12:22:49 PM
Subject: Re: How to add Property to an XSDHelper-defined Type
Hi Frank,
The SDOUtil.createProperty() appears to do what I need with one
caveat. I am currently using the EMF's Diagnostician to validate my
DataObjects since Tuscany SDO does not directly offer such a
capability. The Diagnostician throws an Exception when it encounters
a DataObject whose type modified using SDOUtil.createProperty(). Any
ideas off the top of your head why the Diagnostician might not like
the DataObject with the modified type?
- Ron
- Original Message
From: Frank Budinsky [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Thursday, July 26, 2007 9:50:26 AM
Subject: Re: How to add Property to an XSDHelper-defined Type
Frank Budinsky/Toronto/IBM is out of the office.
I will be out of the office starting 07/28/2007 and will not return until 08/13/2007. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difficulties with static types
Hi Reza, Substitution groups are tricky to work with in SDO. You need to call SDOUtil.getSubstitutionValues(), and then set/add the JavaImplementation property using the Sequence API. I'm not sure I understand why you're trying to generate static SDO for this anyway. The SCA project has its own Java classes for the SCA model, which I would think you should be using. Frank. Reza Shafii [EMAIL PROTECTED] wrote on 09/08/2007 09:52:54 PM: Hi There, I have used the XSD2Java class to generate static types for the SCA core and java schemas. I am having some difficulties setting the implementation element of an instantiated Component static type to a JavaImplementation static type instance. The relevant XSD segments are as follows: complexType name=Component sequence element ref=sca:implementation minOccurs=0 maxOccurs=1/ ... element name=implementation type=sca:Implementation abstract=true / complexType name=Implementation abstract=true ... element name=implementation.java type=sca:JavaImplementation substitutionGroup=sca:implementation/ complexType name=JavaImplementation complexContent extension base=sca:Implementation ... However, my generated objects do not seem to allows me any way (at least by using the generated set() method) to set a JavaImplementationImpl instance as the child of a Component instance. Do Tuscany statically generated types support the above XSD constructs? Thanks, Reza _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx? wx_action=createwx_url=/friends.aspxmkt=en-us - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nesting Helper Contexts
Ron, This kind of chaining of HelperContexts is one of the things being planned for SDO 3. In the meantime, I think you could accomplish it, in a very EMF-specific way, by doing something like this: HelperContext parentHelperContext = SDOUtil.createHelperContext(); HelperContext childHelperContext = new HelperContextImpl( ((HelperContextImpl)parentHelperContext).getExtendedMetaData(), false); I'm not sure, but I think that would do what you want, but be warned that all the EMF-specific parts of Tuscany are considered internal and subject to change in future releases. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 09/13/2007 12:45:02 PM: Greetings, 97% of the model in my application is static and shared by all web sessions. 3% is dynamic and should be unique to each individual web session. Is there a way to scope/nest helper contexts so that all modifications are applied to the child context and lookups are made first to the child context and then to the parent if necessary? This semantic is similar to how classloaders work. Any insight is appreciated. Thanks in advance, - Ron - 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]
Re: XSD2JavaGenerator and non-containment references
Miro,
Both sides of a relationship defined with sdoXML:oppositeProperty need to
be non-containment references. All containment references are implicitly
bidirectional (the reverse is the elements container), so you wouldn't
really want to use an IDREF element anyway - it's just duplicate
information.
To get the SoH from an SoL, you can call:
SoH soh = (SoH)sol.getContainer();
You could manually add a getOrder() (convenience) method in the generated
class like this:
SoH getOrder() { return (SoH)getContainer(): }
EMF has a way to generate this kind of method for you, but there's no
support for this in SDO.
Frank.
Miro Kandic \(mkandic\) [EMAIL PROTECTED] wrote on 09/14/2007 08:40:40
PM:
I am having a problem with new XSD2JavaGenerator (M2 was OK) and it
generates code that cannot be compiled in case when container
element has non-containment reference to the container.
Entire xsd file is attched.
In this case I want to use static API and I want to get sales order
header (SoH) from its lines (SoL) using the same Java code (getter)
as in case when I use corresponding POJO's.
It works fine if property is non-containment reference to no
container class (SoL references product or SoH references Customer).
I am a new in this community and I do not know if this is considered
as a bug who and how should open it. Please, advise.
xsd:complexType name=SoH
xsd:sequence
xsd:element name=customer type=xsd:IDREF sdoxml:
propertyType=impl:Customer sdoxml:oppositeProperty=soHs
minOccurs=1 maxOccurs=1 /
xsd:element name=lines type=impl:SoL minOccurs=0
maxOccurs=unbounded /
xsd:element name=number type=xsd:string
minOccurs=1 maxOccurs=1/
xsd:element name=receivedDate type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=modifiedBy type=xsd:string
minOccurs=1 maxOccurs=1/
xsd:element name=lastUpdated type=xsd:dateTime
minOccurs=1 maxOccurs=1/
xsd:element name=created type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=id type=xsd:long minOccurs=1
maxOccurs=1/
/xsd:sequence
xsd:attribute name=xmlId type=xsd:ID/
/xsd:complexType
xsd:complexType name=SoL
xsd:sequence
xsd:element name=order type=xsd:IDREF sdoxml:
propertyType=impl:SoH sdoxml:oppositeProperty=lines
minOccurs=1 maxOccurs=1 /
xsd:element name=product type=xsd:IDREF sdoxml:
propertyType=impl:Product sdoxml:oppositeProperty=soLs
minOccurs=1 maxOccurs=1 /
xsd:element name=soLineSch type=impl:SoLSch
minOccurs=0 maxOccurs=unbounded /
xsd:element name=quantity type=xsd:double
minOccurs=1 maxOccurs=1/
xsd:element name=requestedDate type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=modifiedBy type=xsd:string
minOccurs=1 maxOccurs=1/
xsd:element name=lastUpdated type=xsd:dateTime
minOccurs=1 maxOccurs=1/
xsd:element name=created type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=id type=xsd:long minOccurs=1
maxOccurs=1/
/xsd:sequence
xsd:attribute name=xmlId type=xsd:ID/
/xsd:complexType
Regards,
Miro
-
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]
RE: XSD2JavaGenerator and non-containment references
minOccurs=1 maxOccurs=1/
xsd:element name=created type=xsd:date
minOccurs=1 maxOccurs=1/
/xsd:sequence
/xsd:extension
/xsd:complexContent
/xsd:complexType
xsd:complexType name=SoH
xsd:sequence
xsd:element name=customer type=xsd:IDREF sdoxml:
propertyType=impl:Customer
sdoxml:oppositeProperty=orders minOccurs=1
maxOccurs=1 /
xsd:element name=lines type=impl:SoL minOccurs=0
maxOccurs=unbounded /
xsd:element name=number type=xsd:string
minOccurs=1 maxOccurs=1/
xsd:element name=receivedDate type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=modifiedBy type=xsd:string
minOccurs=1 maxOccurs=1/
xsd:element name=lastUpdated type=xsd:dateTime
minOccurs=1 maxOccurs=1/
xsd:element name=created type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=id type=xsd:long minOccurs=1
maxOccurs=1/
/xsd:sequence
xsd:attribute name=xmlId type=xsd:ID/
/xsd:complexType
xsd:complexType name=SoL
xsd:sequence
xsd:element name=product type=xsd:IDREF sdoxml:
propertyType=impl:Product
sdoxml:oppositeProperty=soLs minOccurs=1
maxOccurs=1 /
xsd:element name=soLineSch type=impl:SoLSch
minOccurs=0 maxOccurs=unbounded /
xsd:element name=quantity type=xsd:double
minOccurs=1 maxOccurs=1/
xsd:element name=requestedDate type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=modifiedBy type=xsd:string
minOccurs=1 maxOccurs=1/
xsd:element name=lastUpdated type=xsd:dateTime
minOccurs=1 maxOccurs=1/
xsd:element name=created type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=id type=xsd:long minOccurs=1
maxOccurs=1/
/xsd:sequence
xsd:attribute name=xmlId type=xsd:ID/
/xsd:complexType
xsd:complexType name=SoLSch
xsd:sequence
xsd:element name=requestedDate type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=quantity type=xsd:double
minOccurs=1 maxOccurs=1/
xsd:element name=modifiedBy type=xsd:string
minOccurs=1 maxOccurs=1/
xsd:element name=lastUpdated type=xsd:dateTime
minOccurs=1 maxOccurs=1/
xsd:element name=created type=xsd:date
minOccurs=1 maxOccurs=1/
xsd:element name=id type=xsd:long minOccurs=1
maxOccurs=1/
/xsd:sequence
xsd:attribute name=xmlId type=xsd:ID/
/xsd:complexType
xsd:element name=DataGraphRootEl type=impl:DataGraphRoot/
xsd:complexType name=DataGraphRoot
xsd:sequence
xsd:element name=customer type=impl:Customer
minOccurs=0 maxOccurs=unbounded /
xsd:element name=product type=impl:Product
minOccurs=0 maxOccurs=unbounded /
xsd:element name=part type=impl:Part minOccurs=0
maxOccurs=unbounded /
xsd:element name=soH type=impl:SoH minOccurs=0
maxOccurs=unbounded /
/xsd:sequence
/xsd:complexType
/xsd:schema
Miro
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: Mon 9/17/2007 7:49 AM
To: tuscany-user@ws.apache.org
Subject: Re: XSD2JavaGenerator and non-containment references
Miro,
Both sides of a relationship defined with sdoXML:oppositeProperty need
to
be non-containment references. All containment references are implicitly
bidirectional (the reverse is the elements container), so you wouldn't
really want to use an IDREF element anyway - it's just duplicate
information.
To get the SoH from an SoL, you can call:
SoH soh = (SoH)sol.getContainer();
You could manually add a getOrder() (convenience) method in the
generated
class like this:
SoH getOrder() { return (SoH)getContainer(): }
EMF has a way to generate this kind of method for you, but there's no
support for this in SDO.
Frank.
Miro Kandic \(mkandic\) [EMAIL PROTECTED] wrote on 09/14/2007
08:40:40
PM:
I am having a problem with new XSD2JavaGenerator (M2 was OK) and it
generates code that cannot be compiled in case when container
element has non-containment reference to the container.
Entire xsd file is attched.
In this case I want to use static API and I want to get sales order
header (SoH) from its lines (SoL) using the same Java code (getter)
as in case when I use corresponding POJO's.
It works fine if property is non-containment reference to no
container class (SoL references product or SoH references Customer).
I am a new in this community and I do not know if this is considered
as a bug who and how should open it. Please, advise.
xsd:complexType name=SoH
xsd:sequence
xsd:element name=customer type=xsd:IDREF sdoxml:
propertyType=impl:Customer sdoxml:oppositeProperty=soHs
minOccurs=1 maxOccurs=1
RE: XSD2JavaGenerator and non-containment references
Miro,
You're right. The generated method is a little more complicated than I
said. The generated getCircle() method would actually look something like
this:
Circle getCircle() { if (getContainmentProperty() !=
getProperty_Circle_points()) return null; return (Circle)getContainer(); }
And the getPolygon() method, if also requested, would look like this:
Polygon getPolygon() { if (getContainmentProperty() !=
getProperty_Polygon_points()) return null; return (Polygon)getContainer();
}
Note that EMF works exactly this way.
Frank
Miro Kandic \(mkandic\) [EMAIL PROTECTED] wrote on 09/17/2007 02:42:10
PM:
Frank,
maybe solution for the representation of composition (containment)
in XSD and SDO is not so simple.
Recall that one class in UML class diagram can be part of many
compositions but instance of that class, in the run-time, can be
part of only one whole/assembly object (well known example with
class Point that can be part in run-time of either Polygon or Circle
but not both in the same time).
So this would not be solution for this design problem:
xsd:element name=points type=impl:Point
sdojava:getContainer=getCircle minOccurs=0 maxOccurs=unbounded /
because we do not know what is class of point's container in advance.
((DataObject)point.getContainer() should return object either of
Circle or Polygon type and one of static API methods point.
getCyrcle() or point.GetPolygon() will return null and other method
will return something.
I am developing DAS for JPA (EJB 3.0) where DAS accepts set of EJB-
QL queries and returns SDO DataGraph (also applyChanges in opposite
direction) and developing that graph-to-graph transformation of
POJOs graph (not tree) to SDO graph (should be graph not tree) I saw
couple of missing peaces in SDO specification and technology and I
will try to compile that and come back as soon as I can.
Regards,
Miro.
Miro Kandic
(408)525-2596
-Original Message-
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: Mon 9/17/2007 11:01 AM
To: tuscany-user@ws.apache.org
Subject: RE: XSD2JavaGenerator and non-containment references
Miro,
You are right. Bidirectional references are broken in Tuscany. They seem
to have been broken when we switched over to the new (noEMF) codegen
patterns. I guess nobody uses them much and we don't have a test case.
Can
you please open a JIRA bug report to track this?
I understand your point about wanting a static (non SDO dependent) way
to
navigate to the container. I think this is something that we should try
to
change in the next version of SDO. Maybe something like this:
xsd:element name=lines type=impl:SoL
sdojava:getContainer=getOrder minOccurs=0 maxOccurs=unbounded /
Maybe for now in Tuscany, we could just always generate a static method
for getContainer equal to get + container type name. For example, we
would generate:
SoH getSoH() { return (SoH)getContainer(); }
in class SoLImpl. This wouldn't be standard SDO, but a generator is
allowed to generate additional implementation-specific methods and still
be considered compliant.
Frank
Miro Kandic \(mkandic\) [EMAIL PROTECTED] wrote on 09/17/2007
01:09:38
PM:
Frank,
actually XSD2JavaGenerator does not work in the case of any
association type that is navigable from both sides.
I have intentionally, just to test generator, made Customer-SoH
association navigable from both sides and generated code again
cannot be compiled.
Regarding your comments on bidirectional references and
containments, I know I can get container using dynamic SDO API but I
don't want to see in a code that implements business logic any code
that is related to protocols or data implementation technologies.
Packing data to SOAP envelop or sendig data over IIOP is job of
stubs and scaletons and main stream priogrammer should not ever cast
object to classes related to those techologies. Based on the same
principales, business programmer should not be avere that object
he/she is dealing with is actually instance of some Hybernate proxy
or SDO DataObject and should not ever cast those objects to
mentioned classes unless he/she develops some tools or similar
generic software.
And I do not want to use any dynamic API if I don't have to, so I
prefer to have typed Java API and SDO specification explicitally
lists that support as one of the major requirements. So SDO should
support static API defined by XSD schema.
I think Java business programmer should be familiar with UML class
diagrams that define domain and should get only corresponding POJOs
to deal with. Code dealing with data transport or object
distribution or data persistance, where BTW one technology is cool
today and next day another one, should be hidden in adapters,
skeletons and stubs.
Next is complete XSD built automatically from attached UML.
?xml version
Frank Budinsky/Toronto/IBM is out of the office.
I will be out of the office starting 09/18/2007 and will not return until 09/24/2007. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Java SDO CTS] enhancing the CTS
Hi Kelvin, Getting the CTS structured in a way that better reflects exactly what APIs are being tested sounds like a great idea to me. I also like the idea of stub tests so that anybody, with a little time to spare, can easily write/contribute a missing test. Frank. kelvin goodson [EMAIL PROTECTED] wrote on 10/05/2007 07:12:26 AM: I've been thinking about the CTS a bit lately; trying to take stock of what we've got, and how we measure up. The CTS went through a period of healthy growth a while back, but I didn't manage to get a good feel for how well we were covering the API combined with the range of possible inputs to it. I ran the maven clover plugin to try to get some idea of how well we cover the API, but the results show coverage for the implementation classes, and it's not easy to get a good picture for how good the coverage of SDO API interface from that data (For example, there's much code in the Tuscany SDO implementation to support generated code which of course doesn't get exercised by the CTS). Does anyone know of good techniques for getting pure API coverage data? It would be good to get some structure into the CTS to make it more evident in the test code what is covered, and what is not. I'm thinking about perhaps restructuring and adding to the tests to achieve this. I may end up just adding stub tests in the first place in some places to highlight the fact that we are deficient in that area. Kelvin. - 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]
Re: SDO Java - EDataGraph - serialize-transmit (RMI/IIOP)-deserialize then access via *static* SDO API?
In a) you should be using commonj.sdo.DataGraph (implementation class org.apache.tuscany.sdo.impl.DataGraphImpl) because org.eclipse.emf.ecore.sdo.EDataGraph is a specialized interface in the SDO 1 implementation at Eclipse that isn't supported in Tuscany. (if you have both available, it sounds like you're somehow running both SDO 1 and SDO 2 concurrently in your environment.) That aside, you should be able to use static classes in the EJB method, as long as they've been registered (e.g., StaticFactory.register() was called for the EJB scope). Frank. Gary R Martin [EMAIL PROTECTED] wrote on 11/27/2007 09:40:34 AM: By design (with any version of SDO and Tuscany Java implementation), should it be possible to generate static SDO classes from an .xsd, and then: a) use the generated classes to create an: org.eclipse.emf.ecore.sdo.EDataGraph b)call a method on the remote interface of an ejb that takes that EDataGraph as its only arguement c)use the *static* generated SDO classes to access the SDOs in the EDataGraph I've done a) and b) and can use the dynamic SDO API in my EJB method, but, I've yet to figure out how (or even if it should be possible by design) to use the generated static SDO classes in my EJB method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Untyped SDO DataObjects in WebService invocations
Hi Kai,
Dynamic DataObjects should have dynamic types. I'm not sure I understand
exactly what is happening in your example, but DataObject.getType() should
be returning the appropriate types. If it isn't then my guess is that the
metadata wasn't registered/initialized properly.
Frank.
Hudalla Kai (CI/TMP) [EMAIL PROTECTED] wrote on 12/04/2007
09:48:12 AM:
Hi,
I am playing around with the several ways to implement a web service in
Java. Currently I am trying to modify the HelloWorld Web Service SDO
example to support Dynamic DataObjects instead of the generated static
types. Therefore I have modified the HelloWorld interface to use generic
DataObject as parameter and return type.
@Remotable
public interface HelloWorld {
public DataObject getGreetings(DataObject getGreetings);
}
When I implement this interface accordingly and run it I see that the
DataObject instance provided by the Tuscany runtime when invoking the
service is totally untyped, i.e. the type information available in the
WSDL and Schema is not used for deserializing the incoming message to a
DataObject. This is very annoying since it is almost impossible to
access the data contained in the provided DataObject instance because
none of the properties I would expect from the Schema are available.
Is this intended behaviour of the Tuscany container? What is the dynamic
SDO API good for in this case?
Kai
-
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]
Re: Switching from dynamic to static sdo dataobjects
Hi Andrej, There is currently no way to remove types from a scope. Normally you would use two different scopes for your test. For example: HelperContext scope1 = SDOUtil.createHelperContext(); URL url = getClass().getResource(/nl/iteye/sdoexamples/Customer.xsd); scope1.getXSDHelper().define (url.openStream(), url.toString()); // work with the dynamic types in scope1 // ... HelperContext scope2 = SDOUtil.createHelperContext(); StaticSdoFactory.INSTANCE.register (scope2); // work with the static types in scope2 // ... Frank. Andrej Koelewijn [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/03/2008 09:45 AM Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org cc Subject Re: Switching from dynamic to static sdo dataobjects Hi Kelvin, I still have this issue. When i wrote the other thread i didn't understand what was causing the problem, now i know what it is, but i still don't know how to solve it. Thanks, Andrej On 1/3/08, kelvin goodson [EMAIL PROTECTED] wrote: Hi Andrej, Thanks for your notes. I think from your other thread you are sorted with regards to this issue now. Is that right? Regards, Kelvin. On 31/12/2007, Andrej Koelewijn [EMAIL PROTECTED] wrote: Hi, I'm trying to create some test programs with sdo, and one of the tests is that i create a datagraph using dynamic dataobjects (defined using an xsd), save the datagraph and then try to load it using static dataobjects. How do i redefine/reregister dataobjects? If i first define the dynamic types like: URL url = getClass().getResource(/nl/iteye/sdoexamples/Customer.xsd); XSDHelper.INSTANCE.define (url.openStream(), url.toString()); And later reregister the same types, but static generated from the same xsd: HelperContext scope = HelperProvider.getDefaultContext(); StaticSdoFactory.INSTANCE.register (scope); I get ClassCastExceptions when using the static types: java.lang.ClassCastException: org.apache.tuscany.sdo.impl.DynamicDataObjectImpl cannot be cast to nl.iteye.sdoexamples.ex2.Customers Is it possible to clear all type definitions? Thanks, Andrej - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Frank Budinsky/Toronto/IBM is out of the office.
I will be out of the office starting 01/08/2008 and will not return until 01/14/2008. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSD to Java SDO
Hi Sean, The answer to question #1 is that it's not currently possible but the next version of SDO (SDO 3.0) is planning to address this. With SDO 3, you will be able to simply unmarshal JAXB objects (POJOs) and then work with them in a SDO data graph, etc. The SDO API will provide a way for users to effectively cast between static POJOs and DataObjects, where the implementation can either support it using proxies, bytecode injection, or possibly other ways. For question #2, I believe it should be easy enough to do, if somebody (e.g., you :-) is willing to do the work. Basically, a new javajet template will need to be plugged into the generator to optioanlly generate what you want. Frank. Sean Jiang [EMAIL PROTECTED] wrote on 01/17/2008 10:41:14 AM: I have some questions regarding XSD to Java SDO. 1. Can Tuscany Java SDO have light-weight implementation, such as static JAXB binding? In lots of scenarios, only static XML binding is needed. Can Tuscany SDO support JAXB XML binding? 2. Currently Tuscany SDO uses EMF implementation. It generates interfaces and implementation classes from the XSD for each types. When it's integrated with Spring framework and uses dependency injection, you'll need manually create the bean definition file even though the classes are generated from XSD. If the XSD2JavaGenerator can also generate the SDO Spring bean definition file, it would be great. Thanks, Sean - 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]
Re: nonexistent import - XSD2JavaGenerator problem (import org.apache.tuscany.sdo.model.impl.ModelPackageImpl)
It definitely sounds like a bug. The Java code generator went through a major redesign to disconnect it from EMF. It looks like your XSD is invoking a pattern that wasn't converted properly. Maybe you can narrow down which XSD feature is causing this to happend and open a JIRA. Thanks, Frank Stanislaw T. Findeisen [EMAIL PROTECTED] 03/20/2008 03:15 PM Please respond to tuscany-user@ws.apache.org To tuscany-user@ws.apache.org cc Subject nonexistent import - XSD2JavaGenerator problem (import org.apache.tuscany.sdo.model.impl.ModelPackageImpl) Hello In short: this statement: import org.apache.tuscany.sdo.model.impl.ModelPackageImpl is being generated by org.apache.tuscany.sdo.generate.XSD2JavaGenerator, but there is no such class in the current release. This used to work OK with SDO Java Incubating-M2, but now I am upgrading to the current release and this breaks my build. I am trying to generate Java classes corresponding to elements defined in an XSD file. Generated class declaration is this: public class ConfigPackageImpl extends EPackageImpl Am I doing anything wrong, or is this a bug? Thanks! STF - 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]
Re: XSD2JavaGenerator - how to make use of generated classes?
You need to call the register() method on your generated Factory class. For example: MyFactory.INSTANCE.register(myHelperContext); Frank. Stanislaw Findeisen [EMAIL PROTECTED] wrote on 03/31/2008 10:03:23 AM: Hello Could anyone give me an example of how to generate Java classes from XSD files and how to use them later for reading XML files? In our project we are using XSD2JavaGenerator, and later this to read the data: XMLDocument xmlDoc = XMLHelper.INSTANCE.load(inputStream, http://www.pl.ibm.com/esb/config;, null); ConnectionsList sdoConnectionsList = (ConnectionsList) xmlDoc. getRootObject(); where ConnectionsList is a generated Java interface. This used to work with Tuscany SDO M2 release, but now we get this error: Exception in thread main java.lang.ClassCastException: org.apache.tuscany.sdo.impl.AnyTypeDataObjectImpl cannot be cast to com.ibm.pl.esb.config.ConnectionsList Is there any init call we should make prior to this, or maybe we should take some totally different approach? I couldn't find any working example of this in your samples (only dynamic API is used there, that is, DataObject obj = xmlDoc.getRootObject()). Thanks! STF - 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]
Re: Convert HelperContext to XSD
Take a look at XSDHelper.generate(). Frank. Gerardo Corro [EMAIL PROTECTED] wrote on 03/31/2008 10:16:06 AM: Hi, I wonder if theres a way to create a XSD DSO definition from a HelperContext. I mean, the normal process is to setup a HelperContext from an XSD, from there read an XML file that contains the actual DSOs. I want to go the create Types through the API, and then persist them as an XSD. I wonder if there's a way to do that. Thanks _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en- ussource=wlmailtagline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Convert HelperContext to XSD
There's a simple example in XSDHelperTestCase.
testXSDGeneration_DynamicSDOType().
Frank.
Gerardo Corro [EMAIL PROTECTED] wrote on 03/31/2008 11:50:16 AM:
Or even better, if you have a working example of:
XSDHelper.INSTANCE.generate
It will be very appreciated.
Thanks in advanced.
///RG
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]:
RE: Convert HelperContext to XSDDate: Mon, 31 Mar 2008 09:13:52 -0600
Hi, I made an slight adaptation to an existing example of the
distribution, however I get exceptions at runtime. Please assist:
package org.apache.tuscany.samples.sdo.advanced;import java.util.
ArrayList;import java.util.List;import org.apache.tuscany.samples.
sdo.SampleBase;import org.apache.tuscany.sdo.api.SDOUtil;import
commonj.sdo.DataObject;import commonj.sdo.Property;import commonj.
sdo.Type;import commonj.sdo.helper.DataFactory;import commonj.sdo.
helper.HelperContext;import commonj.sdo.helper.TypeHelper;import
commonj.sdo.helper.XSDHelper;public class MedicalScenario1 extends
SampleBase {private static final String sdoApiUri = commonj.
sdo;private static final String peopleURI = www.example.
org/people;private static final String medicalURI = www.
example.org/MedicalTest;boolean typesViaAPI = false;public
MedicalScenario1(String[] args, Integer userLevel) {
super(userLevel, SAMPLE_LEVEL_ADVANCED);typesViaAPI = true;
}public MedicalScenario1(Integer userLevel) {
super(userLevel, SAMPLE_LEVEL_ADVANCED);}/** * @param
args * @throws Exception */public static void
main(String[] args) throws Exception {MedicalScenario1 s =
new MedicalScenario1(args, COMMENTARY_FOR_NOVICE);s.run();
}/* * metadata for the sample documenting the areas of SDO
that are explored */public static int[] CORE_FUNCTION = {
SDOFacets.CONTAINMENT,SDOFacets.
CREATE_TYPES_USING_THE_SDO_API,SDOFacets.
CREATE_TYPES_USING_XML_SCHEMA,SDOFacets.OPEN_CONTENT,
SDOFacets.NON_CONTAINMENT};public static int[]
SIGNIFICANT_FUNCTION = {SDOFacets.
CREATE_DATAOBJECTS_BY_NAME,SDOFacets.ISMANY_PROPERTIES,
SDOFacets.GENERIC_DATA_GRAPH_TRAVERSAL,SDOFacets.
SAVING_DATA_TO_XML};public void runSample() throws Exception
{HelperContext scope = SDOUtil.createHelperContext();
commentary(In this execution of the sample we use Types created\n
+ using the SDO API);createTypesViaAPI(scope);
commentary(COMMENTARY_FOR_NOVICE,
The DataFactory associated with the scope that the types were
created within\n + can be used to create an instance of the Person
Type\n\n + DataFactory dataFactory = scope.getDataFactory();\n +
DataObject person1 = dataFactory.create(\www.example.org/people\,
\Person\););DataFactory dataFactory = scope.
getDataFactory();DataObject person1 = dataFactory.
create(www.example.org/people, Person);commentary(The
setString() of dataObject method is used to set the properties of
the\n + new Person DataObject, including a unique identifier
reference value\n + for the Person instance.\n\n + person1.
setString(\id\, \1\);\n + person1.setString(\name\, \Joe
Johnson Snr.\);\n + person1.setString(\gender\, \male\);););
person1.setString(id, 1);person1.setString(name, Joe
Johnson Snr.);person1.setString(gender, male);
commentary(An alternative approach to using the DataFactory
directly to create\n + all DataObjects is to use a top-down
approach, where we create the\n + root object for a data graph,
and then use the createDataObject(String propertyName)\n + method
to create the contained DataObjects. Here we create the overall\n
+ medical test DataObject, and then create the contained
\referrals\ DataObject\n\n + DataObject test = dataFactory.
create(\www.example.org/MedicalTest\, \Test\);\n + DataObject
referrals = test.createDataObject(\referrals\););
DataObject test = dataFactory.create(www.example.org/MedicalTest,
Test);DataObject referrals = test.
createDataObject(referrals);commentary(Now we can add the
person we created earlier into the set of people who have\n + been
referred for this medical test.\n\n + test.set(\referrals\,
referrals);\n + referrals.getList(\person\).add(person1););
test.set(referrals, referrals);referrals.
getList(person).add(person1);commentary(Let's take a look
at how the current state of the data + graph is rendered in XML
...);System.out.println(scope.getXMLHelper().save(test,
www.example.org/MedicalTest, test));commentary(The
scenario unfolds and the Joe Johnson Snr. becomes a patient\n\n +
DataObject patients = test.createDataObject(\patients\);\n +
patients.getList(\person\).add(person1););DataObject
patients = test.createDataObject(patients);patients.
getList(person).add(person1);
Re: Using Tuscany Java SDO with EMF 2.4
Eric, Theoretically EMF 2.4 should work, because it's supposed to be backward compatible. Have you tracked down exactly what class is missing and why? Frank. Eric S Rose [EMAIL PROTECTED] wrote on 04/15/2008 03:36:49 PM: David, EMF 2.2.3 is what I've been using also up until this point. My code is integrating with a project that's already using EMF 2.4, so I need to align with the larger project. Based on what I've seen so far, it doesn't look like that's a possibility. Thanks, Eric [image removed] David Adcox ---04/15/2008 03:10:11 PM---The latest version I've been using is 2.2.3 - which I believe is what is currently specified in the [image removed] From: [image removed] David Adcox [EMAIL PROTECTED] [image removed] To: [image removed] tuscany-user@ws.apache.org [image removed] Date: [image removed] 04/15/2008 03:10 PM [image removed] Subject: [image removed] Re: Using Tuscany Java SDO with EMF 2.4 The latest version I've been using is 2.2.3 - which I believe is what is currently specified in the pom files. Is there a reason you need to use a newer version of EMF? On Tue, Apr 15, 2008 at 2:09 PM, Eric S Rose [EMAIL PROTECTED] wrote: Hello all, Has anyone had any success running Java SDO with EMF 2.4? I'm running into a NoClassDefFoundError on SDOUtil.createHelperContext(). I've seen this on both the 1.0 and 1.1 releases. Thanks, Eric - 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]
