You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Andy Clark <an...@apache.org> on 2002/01/11 10:50:20 UTC
[Xerces2] Parser Configuration Selection
I'm working on writing some custom parser configurations and
I am running into the same problem again and again: how to take
advantage of the JAXP implementation to automatically create
DOM and SAX parsers that use *my* configuration instead of the
standard Xerces configuration WITHOUT rewriting or copying (and
modifying) any JAXP code.
So I made the attached changes to my local copy of Xerces2 to
implement a similar mechanism to what our JAXP implementation
does. I copied (and renamed) our javax.xml.parsers.FactoryFinder
class to org.apache.xerces.util.ObjectFactory so that we have a
generic tool for dynamically instantiating classes. (Remember
that this code works the "correct" way for both Java 1.1 and
Java 2.)
Then I changed the parser code to use this factory to create
JAXP factories *and* for the Xerces parsers in creating the
default parser configuration that they use. I do this by adding
a new file in the META-INF/services directory. In this way, if
you write a new custom configuration you can override the
default Xerces configuration simply by changing the parser
configuration specified in this file.
I've used it for my own parser configurations and it works
like a champ! But I would like someone to review my changes
before I commit them to the CVS repository.
--
Andy Clark * andyc@apache.org
Re: [Xerces2] Parser Configuration Selection
Posted by Edwin Goei <ed...@sun.com>.
Andy Clark wrote:
>
> Edwin Goei wrote:
> > FactoryFinder class is duplicated already in javax.xml.parsers and
> > javax..transform b/c we don't want it to be exposed as part of JAXP. It
>
> I would not suggest making it part of JAXP. It's just a generic
> way of dynamically instantiating a class that works both in Java
> 1.1 and Java 2. But I thought the whole purpose of xml-commons
> was to reduce the duplication of code. So that's why I proposed
> to put it somewhere in xml-commons.
Not sure if I understand, but what I meant in my previous posting was
that FactoryFinder is a _protected_ class so it does not show up in the
JAXP API. JAXP consists of two packages: javax.xml.parsers and
javax.xml.transform that both need the generic FactoryFinder code, so
that class was essentially duplicated in both packages b/c it had to be
_protected_ and not public. There is similar code that is part of the
internals of the Sun JDK 1.4, but we could not use that b/c the code
needs to run on older versions of the JDK.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [Xerces2] Parser Configuration Selection
Posted by Andy Clark <an...@apache.org>.
Edwin Goei wrote:
> FactoryFinder class is duplicated already in javax.xml.parsers and
> javax..transform b/c we don't want it to be exposed as part of JAXP. It
I would not suggest making it part of JAXP. It's just a generic
way of dynamically instantiating a class that works both in Java
1.1 and Java 2. But I thought the whole purpose of xml-commons
was to reduce the duplication of code. So that's why I proposed
to put it somewhere in xml-commons.
> This will allow anyone else who wants to implement JAXP to take the code
> from xml-commons and not depend on code in Xerces2. I guess an
Seems reasonable.
> alternative would be to move the ObjectFactory code into xml-commons,
> but that has other disadvantages.
I agree. So what do people think is the lesser of two evils?
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [Xerces2] Parser Configuration Selection
Posted by Edwin Goei <ed...@sun.com>.
Andy Clark wrote:
>
> Edwin Goei wrote:
> > So far I've just done a quick scan and I need to go to a dr appt now so
> > I'll think about it some more later. One comment is that the main
> > source for the javax.xml.parsers code actually lives in xml-commons.
> > This allows other parsers to share that code easily. Your changes
> > create a Xerces2 specific version with a dependency on Xerces2 code
> > which would make maintenance more difficult.
>
> Well, for what I want to do, the FactoryFinder class can't be
> used. It would be useful to have a generic way to dynamically
> instantiate objects like the ObjectFactory class I've made. I
> have no problem keeping it in commons but it needs to be in a
> different place than javax.xml.parsers.
>
> I can leave the JAXP implemenation unchanged and still do what
> I need to do but it would be nice if we re-use code. What do
> you think?
Yeah, I agree, but I think we need to take an approach which is least
bad here. I think duplicating code is least bad. The protected
FactoryFinder class is duplicated already in javax.xml.parsers and
javax..transform b/c we don't want it to be exposed as part of JAXP. It
may be a good idea to add comments to ObjectFactory and FactoryFinder
explaining this, so that if there are future bug fixes in the code, they
can be propogated to the other copies. I believe there are comments in
the two FactoryFinder classes to this effect already.
This will allow anyone else who wants to implement JAXP to take the code
from xml-commons and not depend on code in Xerces2. I guess an
alternative would be to move the ObjectFactory code into xml-commons,
but that has other disadvantages.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [Xerces2] Parser Configuration Selection
Posted by Andy Clark <an...@apache.org>.
Edwin Goei wrote:
> So far I've just done a quick scan and I need to go to a dr appt now so
> I'll think about it some more later. One comment is that the main
> source for the javax.xml.parsers code actually lives in xml-commons.
> This allows other parsers to share that code easily. Your changes
> create a Xerces2 specific version with a dependency on Xerces2 code
> which would make maintenance more difficult.
Well, for what I want to do, the FactoryFinder class can't be
used. It would be useful to have a generic way to dynamically
instantiate objects like the ObjectFactory class I've made. I
have no problem keeping it in commons but it needs to be in a
different place than javax.xml.parsers.
I can leave the JAXP implemenation unchanged and still do what
I need to do but it would be nice if we re-use code. What do
you think?
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [Xerces2] Parser Configuration Selection
Posted by Edwin Goei <ed...@sun.com>.
Andy Clark wrote:
>
> I'm working on writing some custom parser configurations and
> I am running into the same problem again and again: how to take
> advantage of the JAXP implementation to automatically create
> DOM and SAX parsers that use *my* configuration instead of the
> standard Xerces configuration WITHOUT rewriting or copying (and
> modifying) any JAXP code.
>
> So I made the attached changes to my local copy of Xerces2 to
> implement a similar mechanism to what our JAXP implementation
> does. I copied (and renamed) our javax.xml.parsers.FactoryFinder
> class to org.apache.xerces.util.ObjectFactory so that we have a
> generic tool for dynamically instantiating classes. (Remember
> that this code works the "correct" way for both Java 1.1 and
> Java 2.)
>
> Then I changed the parser code to use this factory to create
> JAXP factories *and* for the Xerces parsers in creating the
> default parser configuration that they use. I do this by adding
> a new file in the META-INF/services directory. In this way, if
> you write a new custom configuration you can override the
> default Xerces configuration simply by changing the parser
> configuration specified in this file.
>
> I've used it for my own parser configurations and it works
> like a champ! But I would like someone to review my changes
> before I commit them to the CVS repository.
So far I've just done a quick scan and I need to go to a dr appt now so
I'll think about it some more later. One comment is that the main
source for the javax.xml.parsers code actually lives in xml-commons.
This allows other parsers to share that code easily. Your changes
create a Xerces2 specific version with a dependency on Xerces2 code
which would make maintenance more difficult.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [Xerces2] Parser Configuration Selection
Posted by Andy Clark <an...@apache.org>.
I've started a FAQ section for XNI and the first entry is how
to override the default parser configuration.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [Xerces2] Parser Configuration Selection
Posted by Andy Clark <an...@apache.org>.
Okay, I'm committed the support for overriding the default
parser configuration. But I did *not* touch the JAXP impl
to use the new ObjectFactory class.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org