Re: [Tuscany SDO] JIRA-1317 - questions/doubts
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: New test case - XMLOptionsTestCase. Ran complete mvn and cts. 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) Regards, Amita On 6/22/07, Frank Budinsky [EMAIL PROTECTED] wrote: 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_FEATUREare 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/tuscany-dev@ws.apache.org/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
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
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) Regards, Amita On 6/22/07, Frank Budinsky [EMAIL PROTECTED] wrote: 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/tuscany-dev@ws.apache.org/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
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
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/tuscany-dev@ws.apache.org/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
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
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/tuscany-dev@ws.apache.org/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
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Some more questions-
8) are these the only ones? what should be int value to make it ON/OFF?
currently no matter what it is ON, like I put a \n in a attribute value and
loaded in DO and checked
the value there, it was always preserving \n
/**
* Line Break String such as \n, \r\n, \r and , absence/null is
the default (line.separator System Property)
*/
final String XML_SAVE_LINE_BREAK = LineBreak;
/**
* Indent String such as \t, , etc. absence/null is the default (
)
*/
final String XML_SAVE_INDENT = indent;
/**
* Margin String such as , \t\t, etc. Absence/null/ is the
default (no margin)
*/
final String XML_SAVE_MARGIN = margin;
/**
* Attribute formatting that exceeds the specified width as Integer will
cause a line break so that formatting will continue indented on the next
line
*/
final String XML_SAVE_LINE_WIDTH = LINE_WIDTH;
/**
* Boolean to save a doctype declaration
*/
final String XML_SAVE_DOCTYPE = SAVE_DOCTYPE;
/**
* Boolean to process the schemaLocation/noNamespaceSchemaLocation
attributes occurring in the instance document to [EMAIL PROTECTED]
XSDHelper#define
convert XSD(s) to Types}
*/
final String XML_LOAD_SCHEMA = ProcessSchemaLocations;
/**
* To tolerate malformed elements and attributes (default unless set by
System property XML.load.form.lax). 0 not to.
*/
final String XML_LOAD_LAX_FORM = load malform;
Regards,
Amita
On 6/19/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Hi,
In attempt to analyze JIRA-1317, I had some questions and would like to
get some
points clear.
1)Tuscany xmlHelperImpl have load() method where options can be passed in.
Why save() methods with
XMLDocument only have options supported and not for save() methods with
DataObject?
2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in
tuscany-sdo-impl? As this class is
in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of
options implementation in tuscany-sdo-impl,
as these impl classes are not visible in tuscany-sdo-lib.
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();
}
}
}
4)To provide code fix, code will change in (this is what I have thought so
far)
*HelperProviderBase-HelperProviderImpl-HelperContextImpl - constructor
to have options,
*XMLHelperImpl-to have member defaultOptions.
*tuscany-sdo-lib -SDOUtil code - SDOUtil.setDefaultXMLOptions(options)
A typical test case will look like -
public void testXMLOptions() throws IOException{
options = new HashMap();
options.put(SDOHelper.XMLOptions.XML_SAVE_LINE_BREAK, new
Integer(1));
((HelperProviderBase)HelperProvider.INSTANCE).createDefaultHelpers(options);
XMLHelper xmlHelper =
((HelperProviderBase)HelperProvider.INSTANCE).xmlHelper();
String xml=?xml version=\1.0\ encoding=\ASCII\? +
simple:stockQuote xmlns:simple=\
www.example.com/simple\http://www.example.com/simple/
+
symbolfbnt \n /symbol +
companyNameFlyByNightTechnology/companyName +
price1000.0/price +
open11000.0/open1 +
high1000.0/high +
low1000.0/low +
volume1000.0/volume +
change11000.0/change1 +
quotes +
price2000.0/price +
/quotes +
/simple:stockQuote;
XMLDocument xmlDoc = xmlHelper.load(new StringReader(xml), null,
null);
DataObject root = xmlDoc.getRootObject ();
List symbols = root.getList(symbol);
DataObject symbol = (DataObject)symbols.get(0);
String seqValue = (String)symbol.getSequence().getValue(0);
System.out.println(seqValue:+seqValue+ done);
System.out.println(index:+seqValue.indexOf('\n'));
assertEquals(5, seqValue.indexOf('\n'));
}
5)When providing fix for this JIRA, when caller to load/save provides
options, these will override defaultOptions from XMLHelperImpl
6) What is being done in SDOXMLResourceImpl? How options are processed
here?
7) Why SDOUtil is lying in tuscany-sdo-impl and is used in many places?
Are new changes
supposed to be done only in tuscany-sdo-lib/SDOUtil?
Please let me know some details for above and I will be happy to ask more
questions :)
Regards,
Amita
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Hi Amita, I think we must resort to the mailing list since IRC is
failing us, so I'm going to work through the issues and post here as I
go. It won't be as interactive as IRC ought to be, but it will be
better than the reality of IRC :-(
Regards, kelvin.
On 21/06/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Some more questions-
8) are these the only ones? what should be int value to make it ON/OFF?
currently no matter what it is ON, like I put a \n in a attribute value and
loaded in DO and checked
the value there, it was always preserving \n
/**
* Line Break String such as \n, \r\n, \r and , absence/null is
the default (line.separator System Property)
*/
final String XML_SAVE_LINE_BREAK = LineBreak;
/**
* Indent String such as \t, , etc. absence/null is the default (
)
*/
final String XML_SAVE_INDENT = indent;
/**
* Margin String such as , \t\t, etc. Absence/null/ is the
default (no margin)
*/
final String XML_SAVE_MARGIN = margin;
/**
* Attribute formatting that exceeds the specified width as Integer will
cause a line break so that formatting will continue indented on the next
line
*/
final String XML_SAVE_LINE_WIDTH = LINE_WIDTH;
/**
* Boolean to save a doctype declaration
*/
final String XML_SAVE_DOCTYPE = SAVE_DOCTYPE;
/**
* Boolean to process the schemaLocation/noNamespaceSchemaLocation
attributes occurring in the instance document to [EMAIL PROTECTED]
XSDHelper#define
convert XSD(s) to Types}
*/
final String XML_LOAD_SCHEMA = ProcessSchemaLocations;
/**
* To tolerate malformed elements and attributes (default unless set by
System property XML.load.form.lax). 0 not to.
*/
final String XML_LOAD_LAX_FORM = load malform;
Regards,
Amita
On 6/19/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Hi,
In attempt to analyze JIRA-1317, I had some questions and would like to
get some
points clear.
1)Tuscany xmlHelperImpl have load() method where options can be passed in.
Why save() methods with
XMLDocument only have options supported and not for save() methods with
DataObject?
2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in
tuscany-sdo-impl? As this class is
in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of
options implementation in tuscany-sdo-impl,
as these impl classes are not visible in tuscany-sdo-lib.
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();
}
}
}
4)To provide code fix, code will change in (this is what I have thought so
far)
*HelperProviderBase-HelperProviderImpl-HelperContextImpl - constructor
to have options,
*XMLHelperImpl-to have member defaultOptions.
*tuscany-sdo-lib -SDOUtil code - SDOUtil.setDefaultXMLOptions(options)
A typical test case will look like -
public void testXMLOptions() throws IOException{
options = new HashMap();
options.put(SDOHelper.XMLOptions.XML_SAVE_LINE_BREAK, new
Integer(1));
((HelperProviderBase)HelperProvider.INSTANCE).createDefaultHelpers(options);
XMLHelper xmlHelper =
((HelperProviderBase)HelperProvider.INSTANCE).xmlHelper();
String xml=?xml version=\1.0\ encoding=\ASCII\? +
simple:stockQuote xmlns:simple=\
www.example.com/simple\http://www.example.com/simple/
+
symbolfbnt \n /symbol +
companyNameFlyByNightTechnology/companyName +
price1000.0/price +
open11000.0/open1 +
high1000.0/high +
low1000.0/low +
volume1000.0/volume +
change11000.0/change1 +
quotes +
price2000.0/price +
/quotes +
/simple:stockQuote;
XMLDocument xmlDoc = xmlHelper.load(new StringReader(xml), null,
null);
DataObject root = xmlDoc.getRootObject ();
List symbols = root.getList(symbol);
DataObject symbol = (DataObject)symbols.get(0);
String seqValue = (String)symbol.getSequence().getValue(0);
System.out.println(seqValue:+seqValue+ done);
System.out.println(index:+seqValue.indexOf('\n'));
assertEquals(5, seqValue.indexOf('\n'));
}
5)When providing fix for this JIRA, when caller to load/save provides
options, these will override defaultOptions from XMLHelperImpl
6) What is being done in SDOXMLResourceImpl? How options are processed
here?
7) Why SDOUtil is lying in tuscany-sdo-impl and is used in many places?
Are new changes
supposed to be done only in tuscany-sdo-lib/SDOUtil?
Please let
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Amita, I'm going to tackle your questions 1 by 1 On 19/06/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, In attempt to analyze JIRA-1317, I had some questions and would like to get some points clear. 1)Tuscany xmlHelperImpl have load() method where options can be passed in. Why save() methods with XMLDocument only have options supported and not for save() methods with DataObject? So I think here you are referring to a perceived asymmetry in the XMLHelper interfaces. This is a spec issue and I don't have the background to that. I'd like to investigate more, but I got the feeling that form the little bit of the IRC chat that was successful that this was more a curiosity for you. So perhaps we can take this one later, or you can ask the spec group. Response to Q2 coming up ... hope it has more content ... snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
snip/ 2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in tuscany-sdo-impl? As this class is in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of options implementation in tuscany-sdo-impl, as these impl classes are not visible in tuscany-sdo-lib. snip/ Frank Budinsky has the reorganisation of code from just the impl project to an impl/lib split as work in progress [1]. So I guess we need to understand the reason for having ResolvableImpl in the lib project. Without deep investigation my guess is that Frank has good reasons for making the move, so I can see a couple of alternatives, but I need to gain more insight to know which would be best 1) investigate whether the correct home for the options is in the lib project 2) provide some kind of a mapping of options between the impl layer and the lib layer I think it would be good if you could put down your design ideas or provide a prototype patch so that I can see the problem for the wider perspective. Regards, Kelvin. [1] http://issues.apache.org/jira/browse/TUSCANY-1283 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
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]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
4)To provide code fix, code will change in (this is what I have thought so
far)
*HelperProviderBase-HelperProviderImpl-HelperContextImpl - constructor to
have options,
*XMLHelperImpl-to have member defaultOptions.
*tuscany-sdo-lib -SDOUtil code - SDOUtil.setDefaultXMLOptions(options)
A typical test case will look like -
public void testXMLOptions() throws IOException{
options = new HashMap();
options.put(SDOHelper.XMLOptions.XML_SAVE_LINE_BREAK, new Integer(1));
((HelperProviderBase)HelperProvider.INSTANCE).createDefaultHelpers(options);
XMLHelper xmlHelper =
((HelperProviderBase)HelperProvider.INSTANCE).xmlHelper();
String xml=?xml version=\1.0\ encoding=\ASCII\? +
simple:stockQuote
xmlns:simple=\www.example.com/simple\http://www.example.com/simple/
+
symbolfbnt \n /symbol +
companyNameFlyByNightTechnology/companyName +
price1000.0/price +
open11000.0/open1 +
high1000.0/high +
low1000.0/low +
volume1000.0/volume +
change11000.0/change1 +
quotes +
price2000.0/price +
/quotes +
/simple:stockQuote;
XMLDocument xmlDoc = xmlHelper.load(new StringReader(xml), null, null);
DataObject root = xmlDoc.getRootObject();
List symbols = root.getList(symbol);
DataObject symbol = (DataObject)symbols.get(0);
String seqValue = (String)symbol.getSequence().getValue(0);
System.out.println(seqValue:+seqValue+ done);
System.out.println(index:+seqValue.indexOf('\n'));
assertEquals(5, seqValue.indexOf('\n'));
}
Your suggestions appear reasonable. It would be easier for me if you
could provide a prototype patch as the basis for discussion then I can
really get to understand and brush up against the problems first hand.
If you have an issue that you can't see a way to resolve you can
provide a patch that clearly states that this is not the solution,
even if it shows compile failures, then I can help you search for the
solution.
Three are some issues with your test code. First off is the way you
access xmlHelper. Best practice is to create a new HelperContext with
the SDOUtil.createHelperContext methods. If you really need to use
the default instances then you use HelperProvide.getDefaultContext().
The other issue is the way you get the symbol value. If you are using
the existing simple.xsd then I think symbol is single valued, so I
think you can just do ...
String symbol = root.getString(symbol);
Kelvin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
Jumping to Q7 as I need to do something else now for a while and this is an easy one to answer. The SDOUtil in the impl project is what was being used before Frank started on his improvements to the structure. It still exists in deprecated sate to give people a chance to move over. The impl version simple delegates to the api version now. My feeling is that additions ought only to be added to the lib version. If someone needs to make use of the new feature who is still using the deprecated interface then that might provide the incentive to migrate. Regards, kelvin. 7) Why SDOUtil is lying in tuscany-sdo-impl and is used in many places? Are new changes supposed to be done only in tuscany-sdo-lib/SDOUtil? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
The options are moved to lib as well (see org.apache.tuscany.sdo.api.SDOHelper.XMLOptions). Implementation of the options needs to be in the impl project since they have EMF dependencies. Frank. kelvin goodson [EMAIL PROTECTED] wrote on 06/21/2007 05:23:56 AM: snip/ 2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in tuscany-sdo-impl? As this class is in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of options implementation in tuscany-sdo-impl, as these impl classes are not visible in tuscany-sdo-lib. snip/ Frank Budinsky has the reorganisation of code from just the impl project to an impl/lib split as work in progress [1]. So I guess we need to understand the reason for having ResolvableImpl in the lib project. Without deep investigation my guess is that Frank has good reasons for making the move, so I can see a couple of alternatives, but I need to gain more insight to know which would be best 1) investigate whether the correct home for the options is in the lib project 2) provide some kind of a mapping of options between the impl layer and the lib layer I think it would be good if you could put down your design ideas or provide a prototype patch so that I can see the problem for the wider perspective. Regards, Kelvin. [1] http://issues.apache.org/jira/browse/TUSCANY-1283 - 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]
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
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 [EMAIL PROTECTED] 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:
* prefixResourceImpl and prefixResourceFactoryImpl. 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, prefix
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 [EMAIL PROTECTED] 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
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
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
Re: [Tuscany SDO] JIRA-1317 - questions/doubts
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
[Tuscany SDO] JIRA-1317 - questions/doubts
Hi,
In attempt to analyze JIRA-1317, I had some questions and would like to get
some
points clear.
1)Tuscany xmlHelperImpl have load() method where options can be passed in.
Why save() methods with
XMLDocument only have options supported and not for save() methods with
DataObject?
2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in
tuscany-sdo-impl? As this class is
in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of options
implementation in tuscany-sdo-impl,
as these impl classes are not visible in tuscany-sdo-lib.
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();
}
}
}
4)To provide code fix, code will change in (this is what I have thought so
far)
*HelperProviderBase-HelperProviderImpl-HelperContextImpl - constructor to
have options,
*XMLHelperImpl-to have member defaultOptions.
*tuscany-sdo-lib -SDOUtil code - SDOUtil.setDefaultXMLOptions(options)
A typical test case will look like -
public void testXMLOptions() throws IOException{
options = new HashMap();
options.put(SDOHelper.XMLOptions.XML_SAVE_LINE_BREAK, new Integer(1));
((HelperProviderBase)HelperProvider.INSTANCE).createDefaultHelpers(options);
XMLHelper xmlHelper =
((HelperProviderBase)HelperProvider.INSTANCE).xmlHelper();
String xml=?xml version=\1.0\ encoding=\ASCII\? +
simple:stockQuote
xmlns:simple=\www.example.com/simple\http://www.example.com/simple/
+
symbolfbnt \n /symbol +
companyNameFlyByNightTechnology/companyName +
price1000.0/price +
open11000.0/open1 +
high1000.0/high +
low1000.0/low +
volume1000.0/volume +
change11000.0/change1 +
quotes +
price2000.0/price +
/quotes +
/simple:stockQuote;
XMLDocument xmlDoc = xmlHelper.load(new StringReader(xml), null, null);
DataObject root = xmlDoc.getRootObject();
List symbols = root.getList(symbol);
DataObject symbol = (DataObject)symbols.get(0);
String seqValue = (String)symbol.getSequence().getValue(0);
System.out.println(seqValue:+seqValue+ done);
System.out.println(index:+seqValue.indexOf('\n'));
assertEquals(5, seqValue.indexOf('\n'));
}
5)When providing fix for this JIRA, when caller to load/save provides
options, these will override defaultOptions from XMLHelperImpl
6) What is being done in SDOXMLResourceImpl? How options are processed here?
7) Why SDOUtil is lying in tuscany-sdo-impl and is used in many places? Are
new changes
supposed to be done only in tuscany-sdo-lib/SDOUtil?
Please let me know some details for above and I will be happy to ask more
questions :)
Regards,
Amita
