[
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/[email protected]/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. commonj....HelperContext 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 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, 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]
