Since the word "feature" is an EMF term (in SDO it's called "property") I would recommend changing the name of the new option in Tuscany. Something like XMLOptions.XML_LOAD_UNKNOWN_PROPERTIES would be a good name.
Frank. "Amita Vadhavkar" <[EMAIL PROTECTED]> wrote on 06/22/2007 09:33:22 AM: > Hello, > I am trying to summarize the discussion so far below and about to finish the > patch > based on that. I will attach it when tested completely in a day or so. > Please see > the ASSUMPTIONS and PATHS in particular to see if there is some wrong > understanding > there. > > ASSUMPTION: > ---------- > No new load options except XMLResource.OPTION_RECORD_UNKNOWN_FEATURE are > required. This JIRA caters for only load options to be provided by default > and does not consider save options. > > Existing load options > XML_LOAD_SCHEMA - already implemented in SDOXMLResourceImpl > XML_LOAD_LAX_FORM - already implemented in SDOXMLResourceImpl > > Behavior - the above options are required to be passed using xmlhelper.load() > by user. > There is no way at present in tuscany-sdo-lib where user can assume default > options. > This JIRA is to provide this default behavior where XML_LOAD_SCHEMA and > XML_LOAD_LAX_FORM will assume default "true". User will need to pass FALSE > option if this is not desired (For XML_LOAD_SCHEMA - Boolean.FALSE, for > XML_LOAD_LAX_FORM Integer(0)) > > As the mail [Tuscany SDO] JIRA-1317 - questions/doubts says - ResolvableImpl > - is not in working condition, no code changes done to it. > > Also, there is a mail discussion > http://www.mail-archive.com/[email protected]/msg17479.html > which says need to have XML_LOAD_SCHEMA ON by default, it is done using this > JIRA. > > CHANGES: marked with //JIRA-1317 > ---------- > impl > > *XMLHelperImpl > *HelperContextImpl > *HelperProviderImpl > *AllTests > *XLMOptionsTestCase > *SDOHelperImpl > *XMLStreamHelperImpl > > lib > > *SDOUtil > *HelperProviderBase > *SDOHelper > *XMLStreamHelper > > QUESTION: > ---------- > Is there a need to modify CTS for this? or just tuscany-sdo-impl/tests? What > is the standard > convention we follow for Unit Testing JIRA in SDO? > > NOTE: > ---------- > This JIRA does not include anything for > XMLResource.OPTION_RECORD_UNKNOWN_FEATURE. Checking more details for that. > PATHS: > ---------- > HelperProviderBase->HelperProviderImpl->HelperContextImpl->XMLHelperImpl->XMLDocumentImpl > > SDOUtil->SDOHelper->SDOHelperImpl->HelperContextImpl->XMLHelperImpl->XMLDocumentImpl > > SDOUtil->SDOHelperImpl->XMLStreamHelperImpl->XMLDocumentImpl > > Regards, > Amita > > > On 6/22/07, Frank Budinsky <[EMAIL PROTECTED]> wrote: > > > > Amita, > > > > This part of your mapping is wrong: > > > > XML_SAVE_LINE_BREAK OPTION_FORMATTED > > XML_SAVE_INDENT OPTION_FORMATTED > > XML_SAVE_MARGIN OPTION_FORMATTED > > > > These options don't map to anything in EMF. They are Tuscany defined > > options which are processed in SDOXMLResourceImpl. > > > > Frank. > > > > Fuhwei Lwo <[EMAIL PROTECTED]> wrote on 06/21/2007 02:44:55 PM: > > > > > Hi Amita, > > > > > > Currently Tuscany SDO is not exposing all the EMF options for load > > > and save. Also it's not 1:1 mapping from SDO to EMF options. That's > > > why all the supported SDO options are described in the org.apache. > > > tuscany.sdo.api.SDOHelper$XMLOptions. In order to add more options > > > to SDO, you need to modify SDOHelper$XMLOptions then implement the > > > new SDO option by either mapping to EMF's option or implementing > > > your own. Also, I believe load and save options are mutually > > > exclusive which means passing save options to load method will be a > > no-op. > > > > > > In your test case for JIRA 1317, you cannot do something like this: > > > > > > options.put(XMLResource.OPTION_SAVE_DOCTYPE, Boolean.FALSE); > > > > > > because it's using EMF API not SDO's. From a SDO user point > > > of view > > > > > > because it's using EMF API not SDO's. From a SDO user point of view, > > > he/she should not need to import any EMF packages in his/her SDO > > program. > > > > > > Fuhwei > > > > > > Amita Vadhavkar <[EMAIL PROTECTED]> wrote: Hi, > > > I got the below mapping between Tuscany's XMLOptions and emf XMLResource > > > Options > > > Is this what is intended to be passed to in load method, i.e. is it > > expected > > > to > > > have this mapping and pass appropriate options set to the doLoad()? > > Also, we > > > have > > > multiple options for line formatting whereas there is only > > OPTION_FORMATTED > > > in emf XMLResource, so what needs to be done here? > > > Mapping:- > > > > > > XML_SAVE_LINE_BREAK OPTION_FORMATTED > > > XML_SAVE_LINE_BREAK OPTION_FORMATTED > > > XML_SAVE_INDENT OPTION_FORMATTED > > > XML_SAVE_MARGIN OPTION_FORMATTED > > > XML_SAVE_LINE_WIDTH OPTION_LINE_WIDTH > > > XML_SAVE_DOCTYPE OPTION_SAVE_DOCTYPE > > > XML_LOAD_SCHEMA OPTION_SCHEMA_LOCATION > > > XML_LOAD_LAX_FORM OPTION_EXTENDED_META_DATA - already implemented > > > > > > When we talk about moving away from emf, what will happen to these > > options? > > > > > > I am yet to follow all the answers to the questions I had, but after > > passing > > > a couple of > > > options (say OPTION_FORMATTED, OPTION_SAVE_DOCTYPE) and calling load(), > > I > > > see that in > > > SDOXMLResourceImpl.doLoad() that options are getting passed, but I do > > not > > > see any > > > difference in the deserialized DO(see the testcase - dumping do to > > console > > > using xmlhelper) > > > with the option ON/OFF? So what super.doLoad() is > > > doing? > > > > > > I am attaching a patch file JIRA_1317_June21.txt, just to show what code > > > changes I have done so far, this is > > > far away from the solution though. I will collect all answers from this > > > thread and > > > refine the patch, but kind of getting lost with doLoad(). > > > > > > Regards, > > > Amita > > > > > > > > > On 6/21/07, Frank Budinsky wrote: > > > > > > > > The GENERATED_LOADER was used in conjuction with the -generateLoader > > > > option in JavaGenerator. The JavaDoc says this: > > > > > > > > * -generateLoader > > > > * Generate a fast XML parser/loader for instances of the > > model. > > > > The details of this option are > > > > * subject to change, but currently it generates two additional > > > > classes in a "util" package: > > > > * > > > ResourceImpl and > > > ResourceFactoryImpl. To use > > > > the generated loader at runtime, > > > > * you need to pass an option to the XMLHelper.load() method > > like > > > > this: > > > > * Map options = new HashMap(); > > > > * options.put("GENERATED_LOADER", > > > > > > > ResourceFactoryImpl.class); > > > > * XMLDocument doc = XMLHelper.INSTANCE.load(new > > > > FileInputStream("somefile.xml"), null, options); > > > > * Note: this option currently only works for simple schemas > > > > without substitution groups or wildcards. > > > > > > > > Note, however, that this was always an unsupported option (prototype) > > and > > > > it is now completely broken, since we swiched to the -noEMF code > > generator > > > > patterns. > > > > > > > > Frank. > > > > > > > > > > > > "kelvin goodson" wrote on 06/21/2007 05:47:37 > > > > AM: > > > > > > > > > > > > > > > > 3)What is meaning of below code in XMLDocumentImpl? > > > > > > if (options instanceof Map) > > > > > > { > > > > > > Class resourceFactoryClass = > > > > > > (Class)((Map)options).get("GENERATED_LOADER"); > > > > > > if (resourceFactoryClass != null) > > > > > > { > > > > > > try > > > > > > { > > > > > > Object resourceFactory = > > resourceFactoryClass.newInstance(); > > > > > > resourceSet.getResourceFactoryRegistry(). > > > > > getExtensionToFactoryMap().put("*", > > > > > > resourceFactory); > > > > > > } > > > > > > catch (Exception e) > > > > > > { > > > > > > e.printStackTrace(); > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > I looked back at the svn history, and this code has been there > > since > > > > > the original contribution of code to Apache. > > > > > > > > > > My guess from the name of the option and other brushes with topics > > of > > > > > a similar nature is that this allows optimised loads of XML > > documents > > > > > of a specific nature by employing a generated Factory which loads > > only > > > > > documents conforming to s specific XML schema. > > > > > > > > > > It would be good to get a test in place to exercise this code if it > > is > > > > > still relevant. I know for sure that neither the unit tests nor the > > > > > CTS exercises it. > > > > > > > > > > This is standard EMF stuff, but I'm not sure whether we ever put it > > > > > to good use in SDO, so all I can do is translate the meaning of the > > > > > code to the best of my understanding, which you may already > > > > > understand anyway. > > > > > > > > > > In an EMF resource set, there can be a set of Factories that know > > how > > > > > to create java objects from resources. The resource set holds a > > > > > mapping from file extensions for the resources to factories. If a > > > > > request is made to load a resource file with a given extension then > > > > > the map is used to look up the factory that will be used to load the > > > > > resource. There is scope for using wildcards in the file extensions > > in > > > > > the mapping. If you want to override existing behaviour or add new > > > > > file extensions you can add another factory to the mapping. So here > > > > > the one option that seems to be permitted for this operation is the > > > > > "GENERATED_LOADER" option, for which the value must be a class > > which > > > > > is a Factory that knows how to load all resources that the resource > > > > > set is going to encounter. A new instance of this factory is > > created > > > > > and lodged in the resource set's map against the "*" wildcard. So > > > > > whenever the resource set needs to load a resource, the Factory it > > > > > uses to attempt to do the load will always be an instance of the > > class > > > > > that was provided in the option. If the option is not provided or > > > > > the construction of the specified instance fails then the resource > > set > > > > > relies on whatever factories if already knew about to create > > > > > resources. > > > > > > > > > > Regards, Kelvin. > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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]
