Return-Path: 
 <general-return-4990-apmail-xml-general-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-general-archive@xml.apache.org
Received: (qmail 47795 invoked by uid 500); 16 Oct 2001 00:50:25 -0000
Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:general-help@xml.apache.org>
list-unsubscribe: <mailto:general-unsubscribe@xml.apache.org>
list-post: <mailto:general@xml.apache.org>
Reply-To: general@xml.apache.org
Delivered-To: mailing list general@xml.apache.org
Received: (qmail 47784 invoked from network); 16 Oct 2001 00:50:25 -0000
Message-ID: <20011016005034.67027.qmail@web12101.mail.yahoo.com>
Date: Mon, 15 Oct 2001 17:50:34 -0700 (PDT)
From: Shane Curcuru <shane_curcuru@yahoo.com>
Reply-To: shane_curcuru@lotus.com
Subject: Re: javax.xml.parsers.DocumentBuilderFactory
To: general@xml.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

---- you Isaac Shabtay wrote ----
> jaxp.jar contains an implementation of
> javax.xml.parsers.DocumentBuilderFactory. This implementation's
> "newInstance" method does the search using the four steps above. When
it
> comes to step number 4, it looks for Crimson.
>
> So, if tomorrow there'll be another vendor who wants to create a new
XML
> parser that follows JAXP, he'll have to write *his own* version of
> javax.xml.parsers.DocumentBuilderFactory; in his own version, he'll
make
> newInstance() to look for "my.own.document.builder.Factory" instead
of
> "com.sun.blahblah".

Actually I think I disagree.  Users have three chances to override the
defaults; application developers have effectively two.  

One of the major points of the services stuff is that there are
multiple ways that the implementation can be specified - and the search
set is specified.  One of the prime ways is so that any implementer who
supplies a .jar file can supply their own MEAT-INF/services stuff -
which is read before the platform default.  Thus any implementer who
wants their implementation used merely needs to supply this file and
make sure their .jar appears earlier in the classpath than anyone else
who specifies the same service.  Of course users or app developers with
install programs can also always use a jaxp.properties (perhaps site
administrators could use this...) or a system property to specify it. 
Part of this point is that each .jar specifies those implementations
that it supports, making it kind of self-contained.

So there are plenty of ways to override this default setting.  I'd
almost argue that I'd like to see Sun's RI builds explicitly set this,
since those builds supply implementations, and would want those
implementations used if possible (while users could always specifically
override this).  But it doesn't really matter, since the .jars in the
RI builds will always have the META-INF/services stuff set to
themselves, so as long as those .jar files are in the classpath, those
implementations will be used and the default will never be called.

- Shane

=====
<eof aka="mailto:shane_curcuru@lotus.com"
 quote="A mirror is like a window on the other side of behind you."/>

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org