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:
* <prefix>ResourceImpl and <prefix>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", <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 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]
