On 14/08/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > The SCA Java runtime doesn't use the XSD for the assembly or extensions at > runtime to parse the composite file. A StAX-based artifact processor is > plugged into the runtime to handle the extensions such as > implementation.java, implementation.script and binidng.rmi. > > Does SCA Native use the generated SDO from the XSDs to load the composite > file? >
No. SDO C++ does not have a generated SDO feature yet. We load the schema to define types then load the XML to create dynamic SDOs. It was simple. convenient and initially we were using it to test out the SDO code. > Thanks, > Raymond > > ----- Original Message ----- > From: "David Haney" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, August 13, 2007 2:35 PM > Subject: RE: [SCA Native] java implementation and interface schema files > loaded but not used > > > > > > -----Original Message----- > > From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] > > Sent: Friday, August 10, 2007 8:33 AM > > To: [email protected] > > Subject: Re: [SCA Native] java implementation and interface schema > files > > loaded but not used > > > > Brady Johnson wrote: > > > Does anyone have any insight into why these files are loaded but > never > > > used in TuscanySCA Native: > > > > > > <TuscanySCA Root dir>/xsd/ > > > sca-implementation-java.xsd > > > sca-interface-java.xsd > > > > > > I created a JIRA for this: > > > https://issues.apache.org/jira/browse/TUSCANY-1513 > > > > > > Their existence in the project is misleading and implies that > TuscanySCA > > > Native supports Java services. > > > Perhaps these should be removed in M4. > > > > > > > > > -------------------- > > > Brady Johnson > > > Lead Software Developer - HydraSCA > > > Rogue Wave Software - [EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > Will you be able to load (and ignore without breaking) a composite > > containing implementation.java and interface.java elements? I'm > thinking > > about scenarios where people share a composite between the two > runtimes, > > with part of it running on the Native runtime and part running on the > > Java runtime. > > > > I guess I'll have the same question for the Java project, we should be > > able to ignore (or just handle with a warning) implementation.cpp and > > interface.cpp in the Java runtime. > > > > -- > > Jean-Sebastien > > > > Won't this still be a problem for other extensions that are provided by > Tuscany Java? For example, implementation.script? Does this imply that > we should copy all of the extension xsd files from Tuscany Java into > Tuscany Native's /xsd/ directory (and vice versa fro Tuscany Java)? > > Is it possible we could have the composite loader ignore (or warn about) > extension types that it doesn't recognize? This would allow it to parse > the composite files, but wouldn't require that our runtime explicitly > recognize every extension type that isn't supported. > > -- David Haney > -- Chief Architect, Hydra Products > -- Rogue Wave Software > -- http://www.roguewave.com/ > > --------------------------------------------------------------------- > 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] > > -- Pete --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
