I just committed a fix so that now XSDHelper.define() will not hide generated types registered with SDOUtil.registerStaticTypes(). The new behavior is that the first registration, either using XSDHelper.define() or SDOUtil.registerStaticTypes(), of a namespace is the one that will be used. Subsequent calls to define() are a NOOP and will return the existing types.
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. Frank Budinsky/Toronto/[EMAIL PROTECTED] wrote on 03/02/2006 07:47:15 PM: > Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote on 03/02/2006 07:10:55 > PM: > > > Jean-Sebastien Delfino wrote: > > > ant elder wrote: > > >> For the new Axis2 based WS binding we need to get WSDL defined to SDO > so > > >> that the SOAP Body XML can be (de)serialized to DataObjects > > >> correctly. Could > > >> that happen when the import.wsdl in the sca.module is being > > >> processed? Thats > > >> done by org.apache.tuscany.model.assembly.impl.AggregateImpl in the > > >> initialize method. Adding the following line just after the > > >> getAssemblyLoader().loadDefinition call seems to work: > > >> > > >> XSDHelper.INSTANCE.define(url.openStream(), > null); > > >> > > >> Would this be ok? > > >> > > >> Thanks, > > >> > > >> ...ant > > >> > > >> > > > Yes I think this is OK. If your service is flowing complex types and > > > you have generated SDO classes then you just need one of the > > > components in your application module to reference the generated SDO > > > Factory to trigger the initialization of the metadata for your complex > > > > types. But in scenarios flowing elements of simple types e.g. <element > > > > name="getGreetings" type="xsd:string"> you won't have generated SDO > > > classes so you definitely need to invoke > > > XSDHelper.INSTANCE.define(url.openStream(), null) to get the metadata > > > for your elements in place. > > > > > I have a set of related SDO questions - and depending on the answers we > > may have a problem or not :) > > > > Let's say that at build time I give x.wsdl to the SDO code generator. I > > get SDO classes generated for the XSD types defined in my WSDL <types> > > section . Then at runtime I want to use these SDO classes in an SCA > > component. To trigger the initialization of the SDO metadata for these > > types I simply reference the generated factory or use > > SDOUtil.registerStaticTypes(...) when my SCA component starts. Then > > Ant's Axis2 Entry Point runtime does XSDHelper.INSTANCE.define(the exact > > > same x.wsdl)... My understanding is that this will dynamically generate > > SDO metadata from the given WSDL.. > > > > Which version of the metadata is the SDO runtime going to use? the first > > > one that gets registered? the last one? Is XSDHelper going to detect > > that already have SDO metadata registered with static types for the > > given namespace? Do we get new SDO metadata each time we invoke > > XSDHelper.define(...)? > If XSDHelper.define() is called more than once, the second and subsequent > calls just return the already defined types. But this is not true for > statically generated classes. I think that with the current implementation > the dynamically defined model will hide the generated classes. I suppose > I could put a check in XSDHelper.define() to do nothing (just return) if > the namespace is already registered with static classes, if that's what we > want. It's an easy change, but we should think about what the right long > term answer is for this whole issue. > > > > > -- > > Jean-Sebastien > > >
