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
. 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
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
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
.
- 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
' 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
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
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
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
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
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,
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
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
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
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
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):
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
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
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
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
. 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
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
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
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
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,
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
=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
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
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
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
. 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
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
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
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
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
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
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]
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
(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
: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
) 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
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
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
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
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
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
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
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
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
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):
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
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:
.
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 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
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
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
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
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
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
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
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
- 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
Hi Ron,
I guess we would need to make TypeHelper.define support a mode where you
would only
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
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
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
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
/
/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
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
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
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
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
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.
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);
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
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
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
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
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
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.
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.
80 matches
Mail list logo
