Ok thanks. Now I can build it, but when I run my code that functioned before I now get: java.lang.NullPointerException at commonj.sdo.impl.HelperProvider.getXSDHelper(HelperProvider.java:346) at commonj.sdo.helper.XSDHelper.<clinit>(XSDHelper.java:192) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:177) I suppose there are some settings I am lacking?? Any ideas? /Chr
________________________________ From: Yang ZHONG [mailto:[EMAIL PROTECTED] Sent: Sat 2/10/2007 7:28 PM To: [email protected] Subject: [Java] StAX and EMF to build Tuscany in RAD Java 6 has javax.xml.stream (StAX), otherwise you can search RAD for StAX API and impl PlugIn/bundle. There're also free version(s) to download. Tuscany SDO supports EMF 2.2.1 and 2.2.2( http://issues.apache.org/jira/browse/TUSCANY-1102). RAD may support different EMF version in different PlugIn/bundle, just need to declare your dependency specifically. Eclipse newsgroup may be a resource if help needed. On 2/10/07, Christian Landbo Frederiksen < [EMAIL PROTECTED]> wrote: > > I have just checked out the latest build into my Rational Application > Developer 7 (using jdk 1.5) and get some issues with 'javax.xml.stream' > classes that are unknown plus some asm class that is missing. > > Also I have the EMF 2.3 files present but it seems it that they don't > match the Tuscany source... > > Could somebody guide me a bit so that I'm able to build it in my RAD7? > > /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] > -- Yang ZHONG
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
