Hi
I have attached (if this is allowed) the 2 classes I have modified in
Tuscany:
XSDHelperImpl.java - allowed for extensible namespace
SDOXSDEcoreBuilder.java - copied two methods down from XSDEcoreBuilder
and adjusted them to call new addOrReplaceInSortedList method
All my changes have been marked with a NON-TUSCANY comment.
Also attached is TestTypeChangesAndExtensibleNamespaces.java (belongs to
package 'sandbox').
It is a modified cut-down version of my source with a main method that
tests the issues.
Running it gives me:
First define: expecting: TestElementXType, SubElement1 - Double,
SubElement2 - Double
-- traversing properties looking for root --
mixed. Type: EFeatureMapEntry
xMLNSPrefixMap. Type: EStringToStringMapEntry
xSISchemaLocation. Type: EStringToStringMapEntry
TestElementX. Type: TestElementXType
-- --
Root type : TestElementXType
Simple property: SubElement1. Type: Double
Simple property: SubElement2. Type: Double
Second define - extending the namespace: expecting: TestElement2Type,
SubElement1 - Double, SubElement2 - Double
-- traversing properties looking for root --
mixed. Type: EFeatureMapEntry
xMLNSPrefixMap. Type: EStringToStringMapEntry
xSISchemaLocation. Type: EStringToStringMapEntry
TestElementX. Type: TestElementXType
TestElementY. Type: TestElementYType
-- --
Root type : TestElementYType
Simple property: SubElement1. Type: Double
Simple property: SubElement2. Type: Double
Third define - changing existing type: expecting: TestElementXType,
SubElement1 - Integer, SubElement2 - Integer
-- traversing properties looking for root --
mixed. Type: EFeatureMapEntry
xMLNSPrefixMap. Type: EStringToStringMapEntry
xSISchemaLocation. Type: EStringToStringMapEntry
TestElementX. Type: TestElementXType
TestElementY. Type: TestElementYType
TestElementX1. Type: TestElementXType
-- --
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)
at
dk.ementor.sandbox.TestTypeChangesAndExtensibleNamespaces.generate(TestT
ypeChangesAndExtensibleNamespaces.java:138)
at
dk.ementor.sandbox.TestTypeChangesAndExtensibleNamespaces.main(TestTypeC
hangesAndExtensibleNamespaces.java:106)
/Chr
-----Original Message-----
From: Frank Budinsky [mailto:[EMAIL PROTECTED]
Sent: 13. februar 2007 23:43
To: [email protected]
Subject: RE: SDO (Types) Registry
It would be good if you could send us a patch with the changes you made
and a test case you're trying to run. Then we can look at it while we
help
you get it working.
Thanks,
Frank
"Christian Landbo Frederiksen" <[EMAIL PROTECTED]>
wrote on 02/13/2007 04:47:11 PM:
> 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: [email protected]
> 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: [email protected]
> 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: [email protected]
> 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: [email protected]
> > 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: [email protected]
> > > 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: [email protected]
> > > > 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: [email protected]
> > > > > 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: [email protected]
> > > > > 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: [email protected]
> > > > > 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]
>
---------------------------------------------------------------------
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]
