Let me just follow up.
When I don't create the DataObject using the property found on
DocumentRoot
I get an error doing this:
System.out.println(XMLHelper.INSTANCE.save(documentDataObject,
namespace, "TestElementX"));
java.lang.ClassCastException: The feature 'TestElementX's type
'TestElementXType' does not permit a value of type 'TestElementXType'
at
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$BasicFeatureMapEntry.v
alidate(EStructuralFeatureImpl.java:2843)
at
org.eclipse.emf.ecore.util.FeatureMapUtil.createEntry(FeatureMapUtil.jav
a:146)
at
org.eclipse.emf.ecore.util.BasicFeatureMap.createEntry(BasicFeatureMap.j
ava:94)
/Chr
-----Original Message-----
From: Christian Landbo Frederiksen
[mailto:[EMAIL PROTECTED]
Sent: 14. februar 2007 20:58
To: tuscany-user@ws.apache.org
Subject: RE: SDO (Types) Registry
The way I read your answer here is that all my problems have been solved
with the changes done so far.
I fact I did not know that I was trying to add or replace individual
properties in a single type :)
Total redefinition is fine for me.
Now I see it is the way I handle DocumentRoot that is the problem and
this is only due to that fact that I don't know how else to get the
correct property.
If I call DataFactory.INSTANCE.create(namespace, "TestElementXType") I
actually get a dataobject but if I try to generate XML from it the
element isn't called <TestElementX>. That was why I first found the
TestElementX property from the DocumentRoot and the created DataObject
from that.
Is there a way to create a DataObject using
DataFactory.INSTANCE.create(namespace, "TestElementXType") and then
generate XML with property name <TestElementX> ?
/Chr
P.S Is 'Patch' that GNU thing for Linux or is there an eclipse plugin or
something?
-----Original Message-----
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: 14. februar 2007 20:26
To: tuscany-user@ws.apache.org
Subject: RE: SDO (Types) Registry
Looking at your test program, I can see that what you're trying to do is
more than I thought, so it's going to be harder. Let me explain.
In the FIRST part, you define a Type named "TestElementXType". Then in
SECOND, you add a second Type: "TestElementYType", which should work
with
the "true" added to XSDHelper.define(), which allows it to proceed. In
the
THIRD part, you redefine Type "TestElementXType", which should work with
the addToSortedList() change. That's my theory, anyway :-)
What isn't working, since we haven't done anything to support it, is
incremental addition/modification of the properties in a Type. Right
now,
all we have is the ability to add new types or completely replace a type
with a new version (like you're doing for TestElementXType in part
THREE).
You can't add to or replace individual properties in a single type,
which
is what you're also trying to do with the global elements/properties in
the "DocumentRoot" Type.
To test this theory, you could change the global element in the first
schema to something like this:
<element name="RootElement" type="xsd:AnyType"/>
and then delete the global elements in the second and third schemas.
This way, you would define the "DocumentRoot" Type in the first call to
XSDHelper.define() and it would contain the property "RootElement". On
the
second and third calls to TypeHelper.define(), since you have no new
global elements, it won't change/replace the "DocumentRoot", which is
causing the problem.
I think you should try to get this much working first, then we can think
about how to specially handle the DocumentRoot. Note that if we just
change things to allow you to also add new properties or change
properties
in a Type, then it wouldn't be doing the right thing to
"TestElementXType"
in the THIRD part - you would have ended up with a "TestElementXType"
that
has 4 properties (2 double and 2 integer) instead of a redefinition.
Frank.
P.S. please try to get patch working, so that you can send us just the
delta for existing files that you change.
"Christian Landbo Frederiksen" <[EMAIL PROTECTED]>
wrote on 02/14/2007 01:30:41 PM:
> I have created https://issues.apache.org/jira/browse/TUSCANY-1113
>
>
>
> -----Original Message-----
> From: kelvin goodson [mailto:[EMAIL PROTECTED]
> Sent: 14. februar 2007 19:03
> To: tuscany-user@ws.apache.org
> Subject: Re: SDO (Types) Registry
>
> Hi Christian,
> it would be good to get to a stage where we can exchange code and
> replicate issues in quick turnaround and attack this together. I
> haven't
> had a chance to work with the code you attached earlier yet.
>
> Frank suggested attaching the sources you are having problems with to
a
> JIRA. If you were able to do that that would be really helpful. Just
> go to
> http://issues.apache.org/jira/browse/TUSCANY and create a new issue as
> an
> "Improvement" and paste your scenario into the description. Then I
can
> try
> and replicate your issues in an eclipse 3.2 workspace.
>
> It would be good to get you up and running with subversion so that you
> could
> attach patches rather than files. It's tempting to suggest that we
have
> an
> IRC chat on the Tuscany channel and really interactively pursue this
> (there's some info on IRC connection here
> http://incubator.apache.org/tuscany/get-involved.html) . We could
also
> use
> pasetbin (http://pastebin.com/) in conjunction with IRC to quickly
share
> code snippets. Unfortunately I have to leave the office in about 15
> minutes
> (working in UK), but I'll see if I can get back to this later this
> evening. I assume you are in Denmark, yes? I'll make it a priority
to
> try
> to support you interactively either later this evening or in the
> morning. If
> you fancy this then please let me know when is convenient for you.
>
> Best Regards, Kelvin.
>
> On 14/02/07, Christian Landbo Frederiksen <
> [EMAIL PROTECTED]> wrote:
> >
> > Im pretty sure version 7 (which I am using) is based on 3.2 but
> > otherwise you are right :)
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: 14. februar 2007 18:02
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO (Types) Registry
> >
> > Chr:
> >
> > Actually, Rational App. Dev is based on Eclipse 3.0, not the
bleeding
> > edge
> > 3.2. This is a pain for us as well, as we would like to use at least
> 3.1
> >
> > plug-ins for our developers, but it's never a good idea to install
> > Eclipse
> > plug-ins in to RAD (we've had a lot of problems with that,
> particularly
> > the Maven plug-in)
> >
> > -
> > Brandon Werner
> >
> >
> >
> >
> >
> > "Christian Landbo Frederiksen"
> <[EMAIL PROTECTED]>
> >
> > 02/14/2007 11:30 AM
> > Please respond to
> > tuscany-user@ws.apache.org
> >
> >
> > To
> > <tuscany-user@ws.apache.org>
> > cc
> >
> > Subject
> > RE: SDO (Types) Registry
> >
> >
> >
> >
> >
> >
> >
> > I too believe they are related.
> >
> > I am currently using Rational App. Dev. which is based on Eclipse
3.2
> so
> > it ought to be able to do what you mention, otherwise I'll download
> and
> > set it up in Eclipse.
> >
> > A guide to setting it up with regards to patch files would be great.
> > I'll look into submitting this issue via JIRA.
> >
> > Btw. clearing xsdComponentToEModelElementMap didn't help.
> >
> > /Chr
> >
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> > Sent: 14. februar 2007 16:04
> > To: tuscany-user@ws.apache.org
> > Subject: RE: SDO (Types) Registry
> >
> > Hi Christian,
> >
> > My guess is that both of these problems are related. Unfortunately,
I
> > don't have time to look at it myself right now, but my guess is that
> you
> >
> > probably need to make sure the cached mapping (Yang mentioned below)
> is
> > updated. Maybe something like this is needed:
> >
> > public void generate(XSDSchema xsdSchema, boolean forceOverwrite)
> > {
> > if (forceOverwrite) xsdComponentToEModelElementMap.clear();
> > super.generate(xsdSchema);
> > }
> >
> > Yang has volunteered to help get this working, but I think that we
> need
> > a
> > better way to collaborate. Maybe you can open a JIRA request for
this
> > feature and then attach the test case and a patch to it (sending
your
> > changes in emails is very difficult to work with).
> >
> > Are you using Eclipse? If so, you should be able to easily create
> > patch
> > files and apply patch files that Yang (or I) send you. You should
also
> > be
> > able to debug the code (including into the EMF code) to understand
> where
> >
> > things are going wrong. Let us know if you need help setting up an
> > effective development environment.
> >
> > Thanks,
> > Frank
> >
> >
> > "Christian Landbo Frederiksen"
> <[EMAIL PROTECTED]>
> >
> > wrote on 02/14/2007 07:46:23 AM:
> >
> > > Yep those are my 2 problems (at the moment)
> > >
> > > My problem is that I am looking and debugging in the source and
> can't
> > > seem to find out where these things take place.
> > >
> > > /Chr
> > >
> > >
> > > -----Original Message-----
> > > From: Yang ZHONG [mailto:[EMAIL PROTECTED]
> > > Sent: 13. februar 2007 23:18
> > > To: tuscany-user@ws.apache.org
> > > Subject: Re: SDO (Types) Registry
> > >
> > > Very nice to see you participate, it'll be my pleasure to assist
you
> > > through.
> > >
> > > If I understand correctly, there're two problems:
> > >
> > > 2-1. propertyX, propertyX1, propertyX11
> > >
> > > EMF records original element/attribute name from XML schema; let's
> > call
> > > it
> > > XML name.
> > > XML name local part may be not unique, Java identifier has
different
> > > syntax, and CodeGen may need some convention, etc,
> > > so EMF also assigns unique eCore name to
> > properties/EStructuralFeatures.
> > >
> > > EMF derives eCore name from the XML one, and appending 1s to
assure
> > > uniqueness,
> > > so before addToSortedList/addOrReplaceInSortedList, you may want
to
> > > bypass
> > > the 1s appending if XML name matches.
> > > ExtendedMetaData#getNamespace and ExtendedMetaData#getName can
give
> > you
> > > the
> > > XML name.
> > >
> > > 2-2. null eClass.getEPackage()
> > >
> > > EMF contains EClass(complex type) and EDataType(simple type) into
> > > EPackage.
> > > Being kicked out of the List by "set" within
> addOrReplaceInSortedList
> > > will
> > > make the EClass/EDataType *not* contained by the EPackage.
> > > Let me know if you want me to explain more the difference between
> > > containment and non-containment.
> > > EMF/SDO EPackage may have a cache mapping from name to
> > EClass/EDataType,
> > > and EMF/SDO EClass/Type may also have a cache mapping from name to
> > > EStructuralFeature/Property whose type is EClass/EDataType used by
> > code
> > > such
> > > as createDataObject.
> > > You may want to assure those cache are updated accordingly so that
> the
> > > kicked-out EClass/EDataType won't be used since whose
getEPackage()
> is
> > > null.
> > >
> > >
> > > On 2/13/07, Christian Landbo Frederiksen <
> > > [EMAIL PROTECTED]> wrote:
> > > >
> > > > Arghhh just ignore the last one.
> > > >
> > > > I was testing with different namespaces :(
> > > >
> > > > I still have the nullpointer!
> > > >
> > > > Sorry for all the spamming - I'm getting pretty frustrated now.
I
> > > think
> > > > I'll go to bed....
> > > >
> > > > /Chr
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Christian Landbo Frederiksen
> > > > [mailto:[EMAIL PROTECTED]
> > > > Sent: 13. februar 2007 22:40
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: RE: SDO (Types) Registry
> > > >
> > > > Further info:
> > > >
> > > > If I remove the extensibleNamespaces I added to XSDHelperImpl so
> it
> > > > again looks like this:
> > > >
> > > > if (ePackage == null ||
> > > > TypeHelperImpl.getBuiltInModels().contains(ePackage))
> > > >
> > > > The nullpointerexception does not occur but then the existing
> types
> > of
> > > a
> > > > namespace does not seem to respond to changes...
> > > >
> > > > Ought the extensibleNamespaces change stay in:
> > > >
> > > > if (extensibleNamespaces || ePackage == null ||
> > > > TypeHelperImpl.getBuiltInModels().contains(ePackage))
> > > >
> > > > /Chr
> > > >
> > > > -----Original Message-----
> > > > From: Christian Landbo Frederiksen
> > > > [mailto:[EMAIL PROTECTED]
> > > > Sent: 13. februar 2007 21:24
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: RE: SDO (Types) Registry
> > > >
> > > > Hi Frank
> > > >
> > > > I tried adding your code very brute forcely by pulling down
> > > > computeEClass and computeEDataType from XSDEcoreBuilder to
> > > > SDOXSDEcoreBuilder, giving these two methods new names and
calling
> > > them
> > > > from the already existing computeEClass and computeEDataType in
> > > > SDOXSDEcoreBuilder. In the two pulled down methods I call the
> > > > addOrReplaceInSortedList instead of addToSortedList.
> > > >
> > > > When I debug it it seems to do the trick in the
> > > addOrReplaceInSortedList
> > > > method - but once I run it it fails somehow.
> > > >
> > > > The XSDHelper.INSTANCE.define method completes fine using the
new
> > > code,
> > > > but afterward I execute the following (where 'rootElement' is
set
> to
> > > the
> > > > root I seek in the particular invocation):
> > > >
> > > > DataObject documentDataObject =
> > > > DataFactory.INSTANCE.create(namespace, "DocumentRoot");
> > > > List documentProperties =
> > > > documentDataObject.getInstanceProperties();
> > > > Property rootProperty = null;
> > > > for (Iterator i =
> > > documentProperties.iterator();
> > > > i.hasNext();) {
> > > > Property p = (Property) i.next();
> > > > // point 1
> > > > if
> (rootElement.equals(p.getName()))
> > {
> > > > rootProperty = p;
> > > > continue;
> > > > }
> > > > }
> > > >
> > > > if (rootProperty == null) {
> > > > throw new RuntimeException("FOUND
> NO
> > > > ROOT");
> > > > }
> > > >
> > > > if (!rootProperty.isContainment()) {
> > > > throw new RuntimeException("ROOT
IS
> > NOT
> > > > CONTAINMENT: " + rootProperty);
> > > > } else {
> > > > // point 2
> > > > DataObject rootDataObject =
> > > > documentDataObject.createDataObject(rootProperty);
> > > >
> > > > CompositeXmlElement xmlElement =
> new
> > > > CompositeXmlElement(rootDataObject, rootProperty);
> > > > handleRootDataObject(xmlElement);
> > > > return xmlElement;
> > > > }
> > > >
> > > >
> > > > At point 1 I get propertyX, propertyX1, propertyX11 even with
the
> > new
> > > > code that ought to replace propertyX??
> > > >
> > > > At point 2 I now get:
> > > >
> > > > java.lang.NullPointerException
> > > > at
> org.eclipse.emf.ecore.util.EcoreUtil.create(EcoreUtil.java:2970)
> > > > at
> > > >
> > >
> >
>
org.apache.tuscany.sdo.util.DataObjectUtil.create(DataObjectUtil.java:24
> > > > 72)
> > > > at
> > > >
> > >
> >
>
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
> > > > il.java:434)
> > > > at
> > > >
> > >
> >
>
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
> > > > il.java:463)
> > > > at
> > > >
> > >
> >
>
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
> > > > pl.java:1216)
> > > >
> > > > Any ideas (if you can interpret this mail)?
> > > >
> > > > /Chr
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> > > > Sent: 13. februar 2007 18:23
> > > > To: tuscany-user@ws.apache.org
> > > > Subject: RE: SDO (Types) Registry
> > > >
> > > > Hi Christian,
> > > >
> > > > To replace an existing type, you need to override the behavior
of
> > > > XSDEcoreBuilder methods: createEClass() and createEDataType() to
> not
> > > add
> > > > a
> > > > duplicate, but instead replace it when found. I noticed that
they
> > both
> > > > call this method to add the new type:
> > > >
> > > > public static void addToSortedList(List eNamedElements,
> > ENamedElement
> > > > eNamedElement)
> > > > {
> > > > int index = Collections.binarySearch(eNamedElements,
> > eNamedElement,
> > > > Comparator.INSTANCE);
> > > > if (index < 0)
> > > > {
> > > > eNamedElements.add(-(index + 1), eNamedElement);
> > > > }
> > > > else if (eNamedElements.get(index) != eNamedElement)
> > > > {
> > > > eNamedElements.add(index, eNamedElement);
> > > > }
> > > > }
> > > >
> > > > What you want is to do is something like this instead:
> > > >
> > > > public static void addOrReplaceInSortedList(List
eNamedElements,
> > > > ENamedElement eNamedElement)
> > > > {
> > > > int index = Collections.binarySearch(eNamedElements,
> > eNamedElement,
> > > > Comparator.INSTANCE);
> > > > if (index < 0)
> > > > {
> > > > eNamedElements.add(-(index + 1), eNamedElement);
> > > > }
> > > > else if (eNamedElements.get(index) != eNamedElement)
> > > > {
> > > > eNamedElements.set(index, eNamedElement); // overwrite
> existing
> > > > element
> > > > }
> > > > }
> > > >
> > > > The only question, is how best to optionally turn on this
> behavior.
> > I
> > > > think that adding something like this in SDOXSDEcoreBuilder:
> > > >
> > > > protected boolean overwrite = false;
> > > >
> > > > and setting it to true in XSDHelperImpl, when you want this
> > behavior.
> > > >
> > > > Anyway, that's where I'd start. Then you can try to figure out
> where
> > > > best
> > > > to check the variable and change to the alternate
> > > > addOrReplaceInSortedList() behavior.
> > > >
> > > > Let me know how it goes, and if you have any other questions.
> > > >
> > > > Frank.
> > > >
> > > >
> > > > "Christian Landbo Frederiksen"
> > > <[EMAIL PROTECTED]>
> > > >
> > > > wrote on 02/12/2007 03:15:52 PM:
> > > >
> > > > > Hi Frank et. al.
> > > > >
> > > > > First I'll summarize my use case as Yang Zhong requested:
> > > > >
> > > > > An xml schema is uploaded and SDO is used to generate a form
for
> > > > > submitting data as xml-instances of the schema.
> > > > > New schemas in the same namespace may be added often resulting
> in
> > > new
> > > > > forms (this is the first issue where I need to extend existing
> > > > > namespaces).
> > > > >
> > > > > Xml instances may later be edited again.
> > > > > This is the most common use case and SDO seems to support this
> > very
> > > > > well.
> > > > >
> > > > > BUT xml schemas may be modified, even individual types.
> > > > >
> > > > > This of course flagged some warning signs and schema versions
> were
> > > > > considered.
> > > > > But 'use at own risk' was chosen because of its simplicity. To
> > > support
> > > > > this strategy a status/mode will be introduced so
xml-instances
> > > cannot
> > > > > be edited while schema is in 'administration'-mode. This ought
> to
> > > > handle
> > > > > the case with instances at schema-modification time.
> > > > >
> > > > > With regards to serialized xml instances any data that is
> rendered
> > > > > invalid with type changes will be reset/deleted as of design.
> > > > >
> > > > > I sure like the fact that you say it would not be difficult to
> > > > implement
> > > > > replacing existing types and I would greatly appreciate any
help
> > in
> > > > that
> > > > > direction.
> > > > >
> > > > > /Chr
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> > > > > Sent: 12. februar 2007 20:37
> > > > > To: tuscany-user@ws.apache.org
> > > > > Subject: 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/2007 08:36:35 AM:
> > > > > > >
> > > > > > > > Hmmm. I just found this in the Dev list:
> > > > > > > >
> > > > > > > > "In the future, we may want to look at allowing new
types
> to
> > > be
> > > > > > added to
> > > > > > > > an
> > > > > > > > existing namespace, but currently that is not
supported."
> -
> > > > Frank
> > > > > > > > Budinsky
> > > > > > > >
> > > > > > > > If this is not coming up real soon - is there a way to
> > > > circumvent
> > > > > > this
> > > > > > > > using the underlying EMF or something?
> > > > > > > >
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Christian Landbo Frederiksen
> > > > > > > > [mailto:[EMAIL PROTECTED]
> > > > > > > > Sent: 9. februar 2007 14:29
> > > > > > > > To: tuscany-user@ws.apache.org
> > > > > > > > Subject: RE: SDO (Types) Registry
> > > > > > > >
> > > > > > > > And then again - that way I can't define from my xsd.
> > > > > > > >
> > > > > > > > Dang. How do I solve this?
> > > > > > > >
> > > > > > > > /Chr
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Christian Landbo Frederiksen
> > > > > > > > [mailto:[EMAIL PROTECTED]
> > > > > > > > Sent: 9. februar 2007 14:27
> > > > > > > > To: tuscany-user@ws.apache.org
> > > > > > > > Subject: RE: SDO (Types) Registry
> > > > > > > >
> > > > > > > > I have just run into calling define(...) for a schema
with
> > > > > namespace
> > > > > > > > that has already been defined by another schema does NOT
> add
> > > the
> > > > > > types
> > > > > > > > from the new schema.
> > > > > > > >
> > > > > > > > I suppose I have to register each seperately on its own
> > > > > typehelper?
> > > > > > > >
> > > > > > > > Is there a way to see if a namespace is already defined?
> > > > > > > >
> > > > > > > > /Chr
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Yang ZHONG [mailto:[EMAIL PROTECTED]
> > > > > > > > Sent: 27. januar 2007 20:15
> > > > > > > > To: tuscany-user@ws.apache.org
> > > > > > > > Subject: Re: SDO (Types) Registry
> > > > > > > >
> > > > > > > > SDO spec seems not addressing the issues yet, here's
what
> I
> > > know
> > > > > for
> > > > > > > > Tuscany
> > > > > > > > implementation.
> > > > > > > >
> > > > > > > > 1. connection between XSDHelper#define and
XMLHelper#load
> > > > > > > > The assumption is right: XSDHelper#define stores Types
> > into
> > > > > > > > (Package/Types) Registry and XMLHelper#load uses the
Types
> > > from
> > > > > > > > the (Package/Types) Registry
> > > > > > > >
> > > > > > > > 2. How XMLHelper#load uses Types
> > > > > > > > Assuming a XML:
> > > > > > > > <root:stock xmlns:root="NS" ...
> > > > > > > > XMLHelper#load looks for the Type of the global
Property
> > > with
> > > > > > > > NameSpace
> > > > > > > > "NS" and name "stock", and uses the Type to create
> > DataObject
> > > > > > instance
> > > > > > > > then
> > > > > > > > loads the rest of the XML.
> > > > > > > > The Type can be dynamic from XSDHelper#define, where
the
> > > > > > DataObject is
> > > > > > > > an
> > > > > > > > instance of DataObjectImpl.
> > > > > > > > The Type can also be static from code generation,
where
> > the
> > > > > > DataObject
> > > > > > > > is
> > > > > > > > an instance of generated class such as MyStock.
> > > > > > > > If no Type available, XMLHelper#load creates an
instance
> > of
> > > > > > > > AnyTypeDataObject and loads data without any metadata.
> > > > > > > >
> > > > > > > > 3. (Package/Types) Registry Garbage Collection
> > > > > > > > Types are weakly referenced by ClassLoader. If a
(J2EE)
> > > > > > application
> > > > > > > > stops,
> > > > > > > > Types can be Garbage Collected unless a system library
> (live
> > > > > > > > ClassLoader)
> > > > > > > > holds a strong reference.
> > > > > > > >
> > > > > > > > 4. (Package/Types) Registry Thread Safety
> > > > > > > > No Thread Safety for the moment. However it could be
> done;
> > > the
> > > > > > > > previous
> > > > > > > > SDO implementation I worked on supports Thread Safety
for
> > > > example.
> > > > > > > >
> > > > > > > > 5. Two XSDHelper#define for same XSD(s)
> > > > > > > > The later one overwrites the earlier one if same
> > > > > > > > scope/application/ClassLoader. If concurrent, slower
> thread
> > > > "wins"
> > > > > > :-)
> > > > > > > > If different scope/application/ClassLoader, multiple
> > copies
> > > > for
> > > > > > the
> > > > > > > > moment. However it could be optimized to save both
storage
> > and
> > > > > > > > defining/loading time; the previous SDO implementation I
> > > worked
> > > > on
> > > > > > > > defines/loads same XSD(s) only once if no modification
and
> > > makes
> > > > > > Types
> > > > > > > > available to multiple scopes/applications/ClassLoaders,
> for
> > > > > example.
> > > > > > > >
> > > > > > > > On 1/27/07, Christian Landbo Frederiksen <
> > > > > > > > [EMAIL PROTECTED]> wrote:
> > > > > > > > >
> > > > > > > > > I was wondering what goes on in the background, since
> SDO
> > > can
> > > > be
> > > > > > used
> > > > > > > > > the way is is used.
> > > > > > > > >
> > > > > > > > > In the example:
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
org.apache.tuscany.samples.sdo.specCodeSnippets.CreateDataObjectFromXsdA
> > > > > > > > > ndXmlFiles
> > > > > > > > >
> > > > > > > > > types are defined in one static method like this:
> > > > > > > > > XSDHelper.INSTANCE.define(is, null);
> > > > > > > > >
> > > > > > > > > and then in another static method xml is loaded:
> > XMLDocument
> > > > > > xmlDoc =
> > > > > > > > > XMLHelper.INSTANCE.load(is);
> > > > > > > > >
> > > > > > > > > What is the connection between these two separate
method
> > > > > > invocations?
> > > > > > > > > How does the loading of xml use the types defined
above?
> I
> > > > > assume
> > > > > > > > > something is stored somewhere but how does this relate
> to
> > > > > garbage
> > > > > > > > > collection and thread safety? I meas somebody could
call
> > > > > > > > > XSDHelper.INSTANCE.define(is, null); with another xsd
> > > > somewhere
> > > > > > else
> > > > > > > > in
> > > > > > > > > the same VM?
> > > > > > > > >
> > > > > > > > > /Chr
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Yang ZHONG
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > > > 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]
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > 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]
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Yang ZHONG
> > >
> > >
> ---------------------------------------------------------------------
> > > 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]
> >
> >
> >
> >
> >
> > -----------------------------------------
> > CONFIDENTIALITY STATEMENT:
> > This e-mail transmission contains information that is intended to
> > be confidential. It is intended only for the addressee named
> > above. If you receive this e-mail in error, please do not read,
> > copy, or disseminate it. If you are not the intended recipient,
> > any disclosure, copying, distribution or use of the contents of
> > this information is prohibited. Please reply to the message
> > immediately by informing the sender that the message was
> > misdirected. After replying, please erase it from your computer
> > system. Your assistance in correcting this error is appreciated.
> >
> >
---------------------------------------------------------------------
> > 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]
