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.CreateDataObjectFromXs
dA
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]
