You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Stanimir Stamenkov <st...@myrealbox.com> on 2006/10/20 15:42:46 UTC
DOMImplementationRegistry configuration
In examples on using Xerces specific features I see the way
DOMImplementationRegistry instance is obtained is:
System.setProperty(DOMImplementationRegistry.PROPERTY,
"org.apache.xerces.dom.DOMXSImplementationSourceImpl");
DOMImplementationRegistry registry =
DOMImplementationRegistry.newInstance();
I've wondered if it is the best way when using it from a shared
library code as the user application may have setup (through the
"org.w3c.dom.DOMImplementationSourceList" system property) and rely
on other implementation.
As I don't see a reliable way (is there?) to synchronize the
execution of the following example registry instantiation:
String backupRegistry =
System.getProperty(DOMImplementationRegistry.PROPERTY);
System.setProperty(DOMImplementationRegistry.PROPERTY,
"org.apache.xerces.dom.DOMXSImplementationSourceImpl");
DOMImplementationRegistry registry =
DOMImplementationRegistry.newInstance();
if (backupRegistry == null) {
System.getProperties()
.remove(DOMImplementationRegistry.PROPERTY);
} else {
System.setProperty(DOMImplementationRegistry.PROPERTY,
backupRegistry);
}
Could direct instantiation be considered suitable?
DOMImplementationRegistry registry =
new DOMXSImplementationSourceImpl();
... given one uses the exact
|org.apache.xerces.dom.DOMXSImplementationSourceImpl| class name
(although it is marked as internal to the Xerces implementation)
even with the first example and the assertion it must(?) have a
default no-argument constructor.
There are two small drawbacks (or just differences) I see in the
last approach:
1. Creates a direct compilation dependency on the
|org.apache.xerces.dom.DOMXSImplementationSourceImpl| class (which
might be not a bad idea), but the constructor could be invoked
through reflection, also:
DOMImplementationRegistry registry = Class
.forName("org.apache.xerces.dom.DOMXSImplementationSourceImpl")
.newInstance();
2. Creates a new DOMImplementationRegistry instance while the static
factory method probably will return a shared instance. If only that
new instance is used throughout the library, I think that is o.k.
--
Stanimir
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: DOMImplementationRegistry configuration
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Stanimir Stamenkov <st...@myrealbox.com> wrote on 10/24/2006 04:16:41 AM:
> /Michael Glavassevich/:
>
> > When the system property isn't set, DOMImplementationRegistry will
look
> > for a file called
> > META_INF/services/org.w3c.dom.DOMImplementationSourceList in the jars
on
> > the classpath to determine the class name. The one in xercesImpl.jar
> > already points to org.apache.xerces.dom.DOMXSImplementationSourceImpl.
>
> Yes, I'm aware of that mechanism and I've wondered why is the
> |System.setProperty(DOMImplementationRegistry.PROPERTY,
> "org.apache.xerces.dom.DOMXSImplementationSourceImpl")| call ever
> issued in the examples - to ensure the original Xerces
> implementation is in use and not other like the Sun's JDK 5 supplied
> one?
META-INF/services was only added to the look-up mechanism in the final
draft (W3C Recommendation - April 7, 2004) of DOM Level 3. The examples
are much older than that and its probably the case that no one revisited
them. When using the earlier drafts you had to set the system property.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: DOMImplementationRegistry configuration
Posted by Stanimir Stamenkov <st...@myrealbox.com>.
/Michael Glavassevich/:
> When the system property isn't set, DOMImplementationRegistry will look
> for a file called
> META_INF/services/org.w3c.dom.DOMImplementationSourceList in the jars on
> the classpath to determine the class name. The one in xercesImpl.jar
> already points to org.apache.xerces.dom.DOMXSImplementationSourceImpl.
Yes, I'm aware of that mechanism and I've wondered why is the
|System.setProperty(DOMImplementationRegistry.PROPERTY,
"org.apache.xerces.dom.DOMXSImplementationSourceImpl")| call ever
issued in the examples - to ensure the original Xerces
implementation is in use and not other like the Sun's JDK 5 supplied
one?
> If
> you have no control over the environment and you absolutely need to use
> the Xerces implementation I suppose you could use reflection and then
> query the DOMImplementationSource [1] directly.
>
> [1]
> http://xerces.apache.org/xerces2-j/javadocs/api/org/w3c/dom/DOMImplementationSource.html
You're right. I've overlooked this: using direct construction I'll
get DOMImplementationSource and not a DOMImplementationRegistry
instance.
--
Stanimir
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: DOMImplementationRegistry configuration
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
When the system property isn't set, DOMImplementationRegistry will look
for a file called
META_INF/services/org.w3c.dom.DOMImplementationSourceList in the jars on
the classpath to determine the class name. The one in xercesImpl.jar
already points to org.apache.xerces.dom.DOMXSImplementationSourceImpl. If
you have no control over the environment and you absolutely need to use
the Xerces implementation I suppose you could use reflection and then
query the DOMImplementationSource [1] directly.
[1]
http://xerces.apache.org/xerces2-j/javadocs/api/org/w3c/dom/DOMImplementationSource.html
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Stanimir Stamenkov <st...@myrealbox.com> wrote on 10/20/2006 09:42:46 AM:
> In examples on using Xerces specific features I see the way
> DOMImplementationRegistry instance is obtained is:
>
> System.setProperty(DOMImplementationRegistry.PROPERTY,
> "org.apache.xerces.dom.DOMXSImplementationSourceImpl");
> DOMImplementationRegistry registry =
> DOMImplementationRegistry.newInstance();
>
> I've wondered if it is the best way when using it from a shared
> library code as the user application may have setup (through the
> "org.w3c.dom.DOMImplementationSourceList" system property) and rely
> on other implementation.
>
> As I don't see a reliable way (is there?) to synchronize the
> execution of the following example registry instantiation:
>
> String backupRegistry =
> System.getProperty(DOMImplementationRegistry.PROPERTY);
> System.setProperty(DOMImplementationRegistry.PROPERTY,
> "org.apache.xerces.dom.DOMXSImplementationSourceImpl");
> DOMImplementationRegistry registry =
> DOMImplementationRegistry.newInstance();
> if (backupRegistry == null) {
> System.getProperties()
> .remove(DOMImplementationRegistry.PROPERTY);
> } else {
> System.setProperty(DOMImplementationRegistry.PROPERTY,
> backupRegistry);
> }
>
> Could direct instantiation be considered suitable?
>
> DOMImplementationRegistry registry =
> new DOMXSImplementationSourceImpl();
>
> ... given one uses the exact
> |org.apache.xerces.dom.DOMXSImplementationSourceImpl| class name
> (although it is marked as internal to the Xerces implementation)
> even with the first example and the assertion it must(?) have a
> default no-argument constructor.
>
> There are two small drawbacks (or just differences) I see in the
> last approach:
>
> 1. Creates a direct compilation dependency on the
> |org.apache.xerces.dom.DOMXSImplementationSourceImpl| class (which
> might be not a bad idea), but the constructor could be invoked
> through reflection, also:
>
> DOMImplementationRegistry registry = Class
> .forName("org.apache.xerces.dom.DOMXSImplementationSourceImpl")
> .newInstance();
>
> 2. Creates a new DOMImplementationRegistry instance while the static
> factory method probably will return a shared instance. If only that
> new instance is used throughout the library, I think that is o.k.
>
> --
> Stanimir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org