[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX-core #2: factories

• From: David Brownell <david-b@p...>
• To: Michael Brennan <Michael_Brennan@a...>,sax-devel@l...
• Date: Tue, 07 Aug 2001 17:23:13 -0700

In fact I'd probably like to go farther than just adding a
compiled-in default. JAXP has enough bootstrap flexibility,
except it returns something that's not a SAX2 parser.  It
checks four places to find the default (non-SAX) parser
class, I think it's this order:

    * system property (SAX does too) if possible
        --> per-JVM-instance defaulting
    * $(JAVA_HOME)/jre/lib/jaxp.properties
        --> installation-wide defaulting
    * META-INF/services/... resource (usually in jarfile)
        --> can vary based on thread's class loader config
              (threads' loaders may see different resources)
    * compiled-in default (this proposal adds to SAX)
        --> can also vary based on thread's class loader config
              (with different javax.xml.parsers implementations)

Only the compiled-in default can work in all configurations;
access permissions can get in the way of looking up the
default using all the other mechanisms (fragile).

Michael, are you suggesting adding the META-INF/services
support _in addition_ to a compiled-in default?  Or instead
of that?  I wonder if an installation-wide default would be
appropriate (check jaxp.properties?) and whether SAX1
ParserFactory deserves such updates (I'd assume not).

- Dave


----- Original Message -----
From: "Michael Brennan" <Michael_Brennan@a...>
To: "'David Brownell'" <david-b@p...>; <sax-devel@l...>;
<xml-dev@l...>
Sent: Tuesday, August 07, 2001 4:27 PM
Subject: RE: SAX-core #2: factories


> I like this proposal, too. As of JDK 1.3, Sun seems to have adopted the
> convention of putting a file in /META-INF/services named after the service
> interface containing a list of implementation class names. This is what JAXP
> does. I think adopting this approach would be great. (And although the
> convention seems to have started with JDK 1.3, it does not seem to have any
> inherent dependency on 1.3. JAXP just loads the appropriate files via
> ClassLoader.getResourceAsStream.)
>
> > -----Original Message-----
> > From: David Brownell [mailto:david-b@p...]
> > Sent: Tuesday, August 07, 2001 10:05 AM
> > To: sax-devel@l...; xml-dev@l...
> > Subject: SAX-core #2: factories
> >
> >
> > This seems to me most like a bugfix, but I'm sending it for
> > possible discussion in case anyone has issues.
> >
> > Factories
> >
> > - Most distributions don't bother defining a default parser to
> >   use when the appropriate system property isn't set, or access
> >   to it is disallowed (applets etc), though that's allowed by
> >   the spec.  Net result, the SAX bootstrap API is excessively
> >   fragile with respect to environment and configuration.
> >
> >   This encourages initting by calling constructors directly
> >   (and using nonstandard parse APIs), or using other bootstrap
> >   APIs (like JAXP) which provide robust defaults.  Neither of
> >   those is healthy for SAX.
> >
> > PROPOSAL:
> >
> >     - Update javadoc to say clearly that when the system property
> >       can't be accessed, an environment-specific default may be used.
> >
> >     - Encourage distributions to provide such a default; it doesn't
> >       change the API, only increases robustness.
>

• References:
  • RE: SAX-core #2: factories
    • From: Michael Brennan <Michael_Brennan@a...>

• Prev by Date: Interesting article on ASN.1/XML
• Next by Date: Re: [Sax-devel] RE: SAX-ext proposal #4: feature/property discovery
• Previous by thread: RE: SAX-core #2: factories
• Next by thread: RE: SAX-core #2: factories
• Index(es):
  • Date
  • Thread