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,
> 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]
