[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1317: Attachment: 1317.patch It took me a long time to remove all the JIRA-1317 comments, so please if there are any further changes to be made, make them on top of the new revision of the patch that I am attaching. There were lots of changes to the code that were cosmetic only, and in areas where there were no functional changes too, which made the job of reviewing the patch quite difficult. I note that there is a // TODO JIRA-1317 in XMLStreamSerializer but I couldn't tell what was to be done. Please either make the change on top of the attached patch, or make a note here if there is nothing to be done and I will strike the comment before applying the patch. I removed the comment in SDOXMLResourceImpl about changing the default option to TRUE in the future. If we want to change a default option, which I'm disinclined to do because of all the hassle it causes, we should be thinking about doing it right now. Changing default behaviour is a headache for users when they upgrade versions, and I think we have to consider this much more when we apply a 1.0 label to our distributions. Provide a way to set default XML load options to be used during Java deserialization Key: TUSCANY-1317 URL: https://issues.apache.org/jira/browse/TUSCANY-1317 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-beta1, Java-SDO-1.0 Reporter: Daniel Peter Fix For: Java-SDO-1.0 Attachments: 1317.patch, 1317.patch, 1317.patch, 1317.patch, 1317.patch, 1317.patch, 1317.patch, JIRA1317Design.txt, JIRA1317Design.txt, JIRA1317Design.txt, JIRA1317Design.txt, JIRA_1317_June21.txt, JIRA_1317_June25_Amita.txt XML load options can be passed when calling the XMLHelper.load(...) methods. But there is currently no way to pass such load options to be used during Java deserialization. Thus a way to set default load options should be provided, e.g. SDOUtil.setDefaultXMLOptions(HelperContext, Object options) These default options could then be picked up during Java deserialization, i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl. Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be exposed in Tuscany SDO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1317: Attachment: 1317.patch I cleaned up Amita's latest 1317.patch and re-uploaded it. Please review. Thanks. Provide a way to set default XML load options to be used during Java deserialization Key: TUSCANY-1317 URL: https://issues.apache.org/jira/browse/TUSCANY-1317 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-beta1, Java-SDO-1.0 Reporter: Daniel Peter Fix For: Java-SDO-1.0 Attachments: 1317.patch, 1317.patch, 1317.patch, 1317.patch, 1317.patch, 1317.patch, JIRA1317Design.txt, JIRA1317Design.txt, JIRA1317Design.txt, JIRA1317Design.txt, JIRA_1317_June21.txt, JIRA_1317_June25_Amita.txt XML load options can be passed when calling the XMLHelper.load(...) methods. But there is currently no way to pass such load options to be used during Java deserialization. Thus a way to set default load options should be provided, e.g. SDOUtil.setDefaultXMLOptions(HelperContext, Object options) These default options could then be picked up during Java deserialization, i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl. Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be exposed in Tuscany SDO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1317: - Attachment: JIRA1317Design.txt 1317.patch Corrected getMergedOption(), with this there is no need to modify any old test case, i.e. rolled back changes done in SchemaLocationTestCase on Jul 6. Provide a way to set default XML load options to be used during Java deserialization Key: TUSCANY-1317 URL: https://issues.apache.org/jira/browse/TUSCANY-1317 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-beta1, Java-SDO-1.0 Reporter: Daniel Peter Fix For: Java-SDO-1.0 Attachments: 1317.patch, 1317.patch, 1317.patch, 1317.patch, 1317.patch, JIRA1317Design.txt, JIRA1317Design.txt, JIRA1317Design.txt, JIRA1317Design.txt, JIRA_1317_June21.txt, JIRA_1317_June25_Amita.txt XML load options can be passed when calling the XMLHelper.load(...) methods. But there is currently no way to pass such load options to be used during Java deserialization. Thus a way to set default load options should be provided, e.g. SDOUtil.setDefaultXMLOptions(HelperContext, Object options) These default options could then be picked up during Java deserialization, i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl. Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be exposed in Tuscany SDO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1317: - Attachment: JIRA1317Design.txt 1317.patch Changed in patch for Jul 6:- 1)setting XML_LOAD_SCHEMA to FALSE, thus rolled back changes from XMLDocumentTestCase and XMLStreamHelperTestCase, ExtensibleTestCase(tools),but added changes to SchemaLocationTestCase 2)XMLStreamHelper - same support to SAVE options as XMLHelper Please see the comment in SchemaLocationTestCase, if this change is not done, then the default helper context option is not reset back to FALSE. And as the newly introduced code - which merges helper context options with the load() time specified options, the XML_LOAD_SCHEMA option was TRUE for all the test cases following SchemaLocationTestCase, which caused MalFormedURL exception at XMLDocumentTestCase for the previously discussed reasons. So, as long as , we are doing getMergedOptions() in helper context before invokation of load/save, we need to ensure, any test case changing XML_LOAD_SCHEMA from default (FALSE) to TRUE, should take care of resetting it back. 3) Provide a way to set default XML load options to be used during Java deserialization Key: TUSCANY-1317 URL: https://issues.apache.org/jira/browse/TUSCANY-1317 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-beta1, Java-SDO-1.0 Reporter: Daniel Peter Fix For: Java-SDO-1.0 Attachments: 1317.patch, 1317.patch, 1317.patch, 1317.patch, JIRA1317Design.txt, JIRA1317Design.txt, JIRA1317Design.txt, JIRA_1317_June21.txt, JIRA_1317_June25_Amita.txt XML load options can be passed when calling the XMLHelper.load(...) methods. But there is currently no way to pass such load options to be used during Java deserialization. Thus a way to set default load options should be provided, e.g. SDOUtil.setDefaultXMLOptions(HelperContext, Object options) These default options could then be picked up during Java deserialization, i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl. Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be exposed in Tuscany SDO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[
https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amita Vadhavkar updated TUSCANY-1317:
-
Attachment: 1317.patch
Attached clean patch for JIRA 1317.patch dated July 3, this does not have any
code from JIRA 1391 as well as all commented code removed (which was there due
to restructuring of HelperContext-Helpers relationship)
Reason for changes to existing test cases during JIRA 1317 to pass
XML_LOAD_SCHEMA as FALSE explicitly is - Before this JIRA, when no option was
passed, default assumed was FALSE, and the existing test cases passed even
though there were MalFormedURL in the test documents. With default to TRUE
now, the processSchemaLocation option in EMF is set to TRUE and the
MalformedURLs are not ignored.
Say, in XMLDocumentTestCase.testSchemaLocation() - if no FALSE is sent, it
takes path of TRUE as that is the default now. In this, in
SDOXMLResourceImpl.doLoad() {
...
super.doLoad(inputSource, options);
}
the call to super.doLoad() throws the below exception, as due to default true,
xmlOptions.setProcessSchemaLocation(true); takes place.
java.net.MalformedURLException
at java.net.URL.init(URL.java:601)
at java.net.URL.init(URL.java:464)
at java.net.URL.init(URL.java:413)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:968)
at
com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:184)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at
com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:250)
at
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:292)
at
org.eclipse.xsd.util.XSDResourceImpl.getDocument(XSDResourceImpl.java:335)
at
org.eclipse.xsd.util.XSDResourceImpl.getDocument(XSDResourceImpl.java:372)
at org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl.java:680)
at org.eclipse.xsd.util.XSDResourceImpl.load(XSDResourceImpl.java:617)
at
org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:296)
at
org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:286)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$5.generate(SDOXMLResourceImpl.java:532)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processSchemaLocations(XMLHandler.java:1462)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.handleTopLocations(SDOXMLResourceImpl.java:264)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1142)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1247)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:883)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:866)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:627)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(SDOXMLResourceImpl.java:364)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:330)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:779)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1794)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:268)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at
org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:546)
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1317: - Attachment: JIRA1317Design.txt 1317.patch Question: When extensibleNamespaces is not supplied by caller, what should be the default? true/false ** 1. The patch seems to allow the users to specify load/save options at the HelperProvider level. I don't think we want to go that far. Setting options at the HelperContext level should be sufficient in my opinion. This means all the changes like the one below in HelperProvider implementation should not be needed. HelperProviderImpl.createDefaultHelpers(Map options) is not needed. Answer: --- Yes, this sounds proper. For this the changes over the code from 1317.patch(dated June 27) are in - 1HelperProviderBase-remove- public abstract void createDefaultHelpers(Map options); public HelperProviderBase(Map options); 2HelperProviderImpl-remove- public void createDefaultHelpers(Map options) 3XMLOptionsTestCase - remove- testXMLOptionsSchema1() //as we are removing PATH HelperProviderBase-HelperProviderImpl-HelperContextImpl-XMLHelperImpl ** 2. I think in order for XMLHelper and XMLStreamHelper to access options in the HelperContext, we should change the relationship between HelperContext and helper implementations first so all the helpers have a way to access the options stored in the HelperContext. I know only XMLHelper and XMLStreamHelper needs to access the HelperContext's options but I think it's consistent to let all helpers have reference to the HelperContext. Current relationship: HelperContext ---1:1--- TypeHelper ---1:1--- ExtendedMetaData ---1:1--- XMLHelper ---1:1--- ExtendedMetaData XMLStreamHelper ---1:1--- TypeHelper Proposed relationship: HelperContext ---1:1--- ExtendedMetaData ---1:1--- Map (:defaultOption) ---1:1--- TypeHelper ---1:1--- XMLHelper ---1:1--- XMLStreamHelper ---1:1--- XSDHelper ---1:1--- DataFactory - Move ExtendedMetaData var in TypeHelper and XMLHelper to become HelperContextImpl's protected var - New the instance of XMLStreamHelper in the contructor of HelperContext - this will create the association between HelperContext and XMLStreamHelper - Change HelperContextImpl constructor to pass HelperContext instance to the contructor of TypeHelper, XMLHelper, XMLStreamHelper, XSDHelper, and DataFactory so they have reference back to HelperContext for accessing the load/save options at the HelperContext level Answer: This relationship proposal is clean and avoids extra refernces to different instances. --- Multiple changes in below, marked with //JIRA-1317 - for time being kept old code commented, for ref, as there are many changes.Would like to clean up the commented code after final comments for this JIRA tuscany-sdo-impl:- HelperContextImpl TypeHelperImpl XMLHelperImpl XMLStreamHelperImpl XSDHelperImpl DataFactoryImpl ChangeSummaryStreamSerializer SDOUtil (impl) SDOHelperImpl SDODeserializer SDOXMLResourceImpl tuscany-sdo-tools:- --- JavaGenerator XSD2JavaGenerator ExtensibleTestCase ** Provide a way to set default XML load options to be used during Java deserialization Key: TUSCANY-1317 URL: https://issues.apache.org/jira/browse/TUSCANY-1317 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-beta1, Java-SDO-1.0 Reporter: Daniel Peter Fix For: Java-SDO-1.0 Attachments: 1317.patch, 1317.patch, JIRA1317Design.txt, JIRA1317Design.txt, JIRA_1317_June21.txt, JIRA_1317_June25_Amita.txt XML load options can be passed when calling the XMLHelper.load(...) methods. But there is currently no way to pass such load options to be used during Java deserialization. Thus a way to set default load options should be provided, e.g. SDOUtil.setDefaultXMLOptions(HelperContext, Object options) These default options could then be picked up during Java deserialization, i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl. Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be exposed in Tuscany SDO. -- This message is automatically generated by JIRA. - You can reply to this
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1317: - Attachment: 1317.patch JIRA1317Design.txt Hi, 1)As the name of JIRA-1317 implies, it is only for load options and not for save options. So the code changes I am attaching to 1317.patch are only for load options. Please see the design document attached to the JIRA for detailed changes done. Questions- 1Is there a need to modify CTS for this? or just tuscany-sdo-impl/tests? What is the standard convention we follow for SDO Unit Testing? 2 Also, another doubt on same lines, in SDOXMLResourceImpl.doLoad(), else for if(options != null) is never executed(checked all test cases, that this path is never taken), as in DataObjectUtil.configureXMLResource (), some default options are always set. So, what is the purpose of having this code? 2)I will create new JIRA for www.mail-archive.com/[EMAIL PROTECTED]/msg01000.html- with title - serialize/deserialize extra properties in SDO/XML (using XMLResource.OPTION_RECORD_UNKNOWN_FEATURE) Quenstions - When during deserialization, we get 0..n AnyDataObjects for these extra features/properties, what should be the design to make space for these? Say, have a new Property (named AdditionalProperties) added to root DataObject and save all the AnyDataObjects (bunched in one DataObject under containment) against this property? So, when the caller says doc.getRootObject().getDataObject(AdditionalProperties), he will get handle for this? i.e. in details say, in XMLDocumentImpl - similar to initLoadedRoot(), have another method initAdditionalObject() to modify member EObject rootObject to add this new DataObject? This is my first JIRA in SDO, and so I may be deviating from the right approach, so please give me all your suggestions, naming conventions for new methods, members etc. 3)Shall I created new JIRA-with title- Provide a way to set default XLM save options to be used during Java serialization? We have 12.5 hrs time difference due to our time zones (IST and PDT). I will try to be online tonight and see if we can chat for the above, so I can work tomorrow on 2) and 3). I guess, as you will get the patch today for review, it may be better, if we can have a scheduled chat tomorrow again, i.e. June 28, 9.30 a.m. PDT, when I can get my doubts clear for your review comments on 1) and if possible review 2) and 3). Thanks and with best regards, Amita Provide a way to set default XML load options to be used during Java deserialization Key: TUSCANY-1317 URL: https://issues.apache.org/jira/browse/TUSCANY-1317 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-beta1, Java-SDO-1.0 Reporter: Daniel Peter Fix For: Java-SDO-1.0 Attachments: 1317.patch, JIRA1317Design.txt, JIRA_1317_June21.txt, JIRA_1317_June25_Amita.txt XML load options can be passed when calling the XMLHelper.load(...) methods. But there is currently no way to pass such load options to be used during Java deserialization. Thus a way to set default load options should be provided, e.g. SDOUtil.setDefaultXMLOptions(HelperContext, Object options) These default options could then be picked up during Java deserialization, i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl. Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be exposed in Tuscany SDO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1317: - Attachment: JIRA_1317_June25_Amita.txt Hello, I have created patch JIRA_1317_June25_Amita.txt attached to ASF-JIRA. Below is the brief design and changes done to each class. Please give your comments/recommendetions I will be sending separate mail for XMLResource.OPTION_RECORD_UNKNOWN_FEATURE. ML - www.mail-archive.com/[EMAIL PROTECTED]/msg01000.html Where shall I create patch for it? (1-2 more days)(i.e. shall I append patch for this to JIRA-1317 or create a new JIRA, to keep the work separate?) ASSUMPTION: -- No new load options are covered in this JIRA. XMLResource.OPTION_RECORD_UNKNOWN_FEATURE will be treated using another JIRA so as not to mix different issues into one. This JIRA caters for only load options to be provided by default and does not consider save options. Existing: - Existing load options XML_LOAD_SCHEMA - already implemented in SDOXMLResourceImpl (Default behavior - FALSE) -When TRUE, loads an xml document consisting of a xsi:schemaLocation and xsi:noNamespaceSchemaLocation defined. It will then use the XMLDocument API to get and set the schemaLocation property. XML_LOAD_LAX_FORM - already implemented in SDOXMLResourceImpl (Default bahavior - ON == 1) -When 0, elements/attributes not adhering to xsd, cause exception during load -When 1, document loads without exceptions Existing Behavior - There was no/partial way to pass options to, during xmlhelper.load() or xmlStreamHelper.loadObject(), default values are assumed. The above options are required to be passed by user if different behavior is expected. There is no way at present in tuscany-sdo-lib where user can set options at HelperContext level, which can then be used by all load() calls to XMLHelper. New: New Behavior - This JIRA provides methods so that user can set the behavior once per HelperContext and use it for all later use of XMLHelper, XMLStreamHelper. In this case, user does not need to pass options to load(). If user still passes options to load(), these will override what is set in the HelperContext for that particular invocation of load(). Also, there is a mail discussion http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17479.html which says need to have XML_LOAD_SCHEMA TRUE by default, it is done using this JIRA. CHANGES: in code marked with //JIRA-1317 -- tuscany-sdo-impl 1*XMLHelperImpl 2*HelperContextImpl 3*HelperProviderImpl 4*AllTests 5*XLMOptionsTestCase 6*SDOHelperImpl 7*XMLStreamHelperImpl 8*SDOXMLResourceImpl tuscany-sdo-lib 9*SDOUtil 10*HelperProviderBase 11*SDOHelper 12*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 DAS? PATHS: These are the different flows used during setting options. -- 1)HelperProviderBase-HelperProviderImpl-HelperContextImpl-XMLHelperImpl-XMLDocumentImpl 2)SDOUtil-SDOHelper-SDOHelperImpl-HelperContextImpl-XMLHelperImpl-XMLDocumentImpl 3)SDOUtil-SDOHelper-SDOHelperImpl-XMLStreamHelperImpl-XMLDocumentImpl 4)SDOUtil-SDOHelper-SDOHelperImpl-HelperContextImpl-XMLStreamHelperImpl-XMLDocumentImpl TEST: Ran complete mvn and cts. New test case - XMLOptionsTestCase. General design thought: --- HelperContextImpl has new member defaultOptions. These can be set by The same are referenced by XMLHelper and XMStreamHelper if there are no explicit options passed to their load(), loadObject() methods. So far, XMLStreamHelper was not bunched with other helpers like XMLHelper, XSDHelper under HelperContextImpl. This JIRA has made that change, so that the path 4) is possible. But this needs spec support , i.e. commonjHelperContext should provide getXMLStreamHelper(). Due to this change, internal to Tuscany-SDO it is possible to have only one member defaultOption at context level, instead of duplicating it at XMLHelper and XMLStreamHelper level. Done changes to HelperContextImpl-XMLStreamHelperImpl for this. Also, HelperContext should be reachable from helpers, so that the context level information can be shared.At present made this to only XMLHelper and XMLStreamHelper, but if this sounds the appropriate change, it should be made to other helpers as well like XSDHelper.., to keep design consistent. Probably this was not needed before as so far HelperContextImpl held only these helpers and a static builtInModelRegistry. But as helpers are instance members, options have to be instance member of HelperContextImpl and also reachable from Helpers bunched under the same context. So introduced member Map defaultOptions in HelperContextImpl, and pass helperContextImpl ref. to Helpers (at present only XMLHelper and XMStreamHelper) Provide a way to set default XML load options
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1317: - Attachment: JIRA_1317_June21.txt Please see the patch JIRA_1317_June21.txt, it is just the work I did so far and noway the solution. Also, working on the mail thread comments, will refine patch based on that. Provide a way to set default XML load options to be used during Java deserialization Key: TUSCANY-1317 URL: https://issues.apache.org/jira/browse/TUSCANY-1317 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-beta1, Java-SDO-1.0 Reporter: Daniel Peter Fix For: Java-SDO-1.0 Attachments: JIRA_1317_June21.txt XML load options can be passed when calling the XMLHelper.load(...) methods. But there is currently no way to pass such load options to be used during Java deserialization. Thus a way to set default load options should be provided, e.g. SDOUtil.setDefaultXMLOptions(HelperContext, Object options) These default options could then be picked up during Java deserialization, i.e. in the method readDataObject in class HelperProviderImpl.ResolvableImpl. Additionally the XMLResource.OPTION_RECORD_UNKNOWN_FEATURE option could be exposed in Tuscany SDO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
