You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Matt Liotta <ml...@r337.com> on 2003/02/14 14:15:50 UTC
Xerces dependency
Any plans to remove the Xerces dependency from Xindice and support JAXP
instead?
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
Re: Xerces dependency
Posted by "Mark J. Stang" <ma...@earthlink.net>.
Matt,
I might be interested. I have been working on Xindice since it was dbXML.
I am currently using it in my project.
regards,
Mark
Matt Liotta wrote:
> Actually I wasn't volunteering, but if no one else is working on it then
> my company will likely tackle the problem in the coming months. I just
> didn't want to waste resources on work someone else was doing.
>
> BTW, any Xindice hackers out there who are looking for contract work
> implementing changes to Xindice?
>
> Matt Liotta
> President & CEO
> Montara Software, Inc.
> http://www.montarasoftware.com/
> 888-408-0900 x901
>
> > -----Original Message-----
> > From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
> > Sent: Friday, February 14, 2003 8:24 AM
> > To: xindice-dev@xml.apache.org
> > Subject: Re: Xerces dependency
> >
> > > Any plans to remove the Xerces dependency from Xindice and support
> JAXP
> > > instead?
> >
> > Thank you for volunteering :-)
> >
> > I'm not aware of any plan but if JAXP is smaller, faster you have my
> +1.
> >
> > -Vladimir
> >
> > --
> > Vladimir R. Bossicard
> > Apache Xindice - http://xml.apache.org/xindice
--
Mark J Stang
System Architect
Cybershop Systems
RE: Xerces dependency
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
>>>will it still be necessary for Xindice to be shipped with
Xerces???.jar?
Well, yes and no.
Xindice would still need a parser. Even though jdk 1.4.1 has one, that
doesn't mean it is our recommended version. That also doesn't help our
fellow users with older versions of the jdk. So, it is really still in
regardless (because we want the package to run as-is), but that doesn't
stop you from repackaging or deploying differently.
-Kevin Ross
-----Original Message-----
From: Lixin Meng [mailto:lxmeng@yahoo.com]
Sent: Friday, February 14, 2003 2:10 PM
To: xindice-dev@xml.apache.org
Subject: RE: Xerces dependency
I also did a test that removing the xerces???.jar from
xml-xindice/java/lib
directory. It doesn't seem affect the build nor basic query (I didn't
test
the RPC staff though).
Is this because I am using j2sdk1.4.1, which already has xerces? If the
problem Kevin mentioned solved,
Regards,
Lixin
-----Original Message-----
From: Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Sent: Friday, February 14, 2003 11:43 AM
To: xindice-dev@xml.apache.org
Subject: RE: Xerces dependency
The dependency I found seems to lie in the XmlRpc.setDriver("xerces")
scattered throughout.
It seems that (http://ws.apache.org/xmlrpc/parser.html) you should be
able to change that easily, by making this configurable (xindice config)
and using the configured implementation in the code.
Just my thoughts from a little perusing...
-Kevin Ross
-----Original Message-----
From: Matt Liotta [mailto:mliotta@r337.com]
Sent: Friday, February 14, 2003 12:27 PM
To: xindice-dev@xml.apache.org
Subject: RE: Xerces dependency
I believe I remember seeing comments in the code about the dependency
thus implying to me at least that removal of the dependency would be
non-trivial. However, we have found a business need to remove the Xerces
dependency and figured the project could benefit.
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
> -----Original Message-----
> From: Gianugo Rabellino [mailto:gianugo@apache.org]
> Sent: Friday, February 14, 2003 12:47 PM
> To: xindice-dev@xml.apache.org
> Subject: Re: Xerces dependency
>
> Matt Liotta wrote:
> > Actually I wasn't volunteering, but if no one else is working on it
then
> > my company will likely tackle the problem in the coming months. I
just
> > didn't want to waste resources on work someone else was doing.
> >
>
> That would be cool. However, I'm not dead sure that the Xerces
> dependancy can be removed easily from the current codebase. I think
that
> some of the Xindice internals rely on some Xerces code (not exposed by
> Jaxp). This is for sure the case with Xalan, on which the source
relies
> for the XPath compiler (and, BTW, XUpdate too depends on Xalan).
>
> > BTW, any Xindice hackers out there who are looking for contract work
> > implementing changes to Xindice?
>
> Oh well... you have my e-mail, don't you? ;-)
>
> Ciao,
>
> --
> Gianugo Rabellino
> CTO
> Pro-netics s.r.l.
> http://www.pro-netics.com
RE: Xerces dependency
Posted by Lixin Meng <lx...@yahoo.com>.
I put crimson.jar (1.1.3) in j2sdk1.4.1_01\lib\endorsed directory, and
removed external Xerces jar files. Both of building and executing (no RPC)
work fine. But Vladimir's tests will have final say.
Lixin
-----Original Message-----
From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
Sent: Friday, February 14, 2003 12:44 PM
To: xindice-dev@xml.apache.org
Subject: Re: Xerces dependency
> I believe JDK1.4.1 comes with Xerces as the default JAXP parser. I am
> specifically interested in seeing Xindice work with parsers like
> Crimson.
Well the quickest way to find it out is to try :-) I will commit some
tests for the XPath and XUpdate services this week-end so with the
available unit and integration tests, you can quickly figure out what's
working and what's not.
Feedback welcome
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
Re: Xerces dependency
Posted by "Vladimir R. Bossicard" <vl...@apache.org>.
> I believe JDK1.4.1 comes with Xerces as the default JAXP parser. I am
> specifically interested in seeing Xindice work with parsers like
> Crimson.
Well the quickest way to find it out is to try :-) I will commit some
tests for the XPath and XUpdate services this week-end so with the
available unit and integration tests, you can quickly figure out what's
working and what's not.
Feedback welcome
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
RE: Xerces dependency
Posted by Matt Liotta <ml...@r337.com>.
I believe JDK1.4.1 comes with Xerces as the default JAXP parser. I am
specifically interested in seeing Xindice work with parsers like
Crimson.
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
> -----Original Message-----
> From: Lixin Meng [mailto:lxmeng@yahoo.com]
> Sent: Friday, February 14, 2003 3:10 PM
> To: xindice-dev@xml.apache.org
> Subject: RE: Xerces dependency
>
> I also did a test that removing the xerces???.jar from xml-
> xindice/java/lib
> directory. It doesn't seem affect the build nor basic query (I didn't
test
> the RPC staff though).
>
> Is this because I am using j2sdk1.4.1, which already has xerces? If
the
> problem Kevin mentioned solved, will it still be necessary for Xindice
to
> be
> shipped with Xerces???.jar?
>
> Regards,
> Lixin
>
> -----Original Message-----
> From: Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
> Sent: Friday, February 14, 2003 11:43 AM
> To: xindice-dev@xml.apache.org
> Subject: RE: Xerces dependency
>
>
> The dependency I found seems to lie in the XmlRpc.setDriver("xerces")
> scattered throughout.
>
> It seems that (http://ws.apache.org/xmlrpc/parser.html) you should be
> able to change that easily, by making this configurable (xindice
config)
> and using the configured implementation in the code.
>
> Just my thoughts from a little perusing...
>
> -Kevin Ross
>
> -----Original Message-----
> From: Matt Liotta [mailto:mliotta@r337.com]
> Sent: Friday, February 14, 2003 12:27 PM
> To: xindice-dev@xml.apache.org
> Subject: RE: Xerces dependency
>
> I believe I remember seeing comments in the code about the dependency
> thus implying to me at least that removal of the dependency would be
> non-trivial. However, we have found a business need to remove the
Xerces
> dependency and figured the project could benefit.
>
> Matt Liotta
> President & CEO
> Montara Software, Inc.
> http://www.montarasoftware.com/
> 888-408-0900 x901
>
> > -----Original Message-----
> > From: Gianugo Rabellino [mailto:gianugo@apache.org]
> > Sent: Friday, February 14, 2003 12:47 PM
> > To: xindice-dev@xml.apache.org
> > Subject: Re: Xerces dependency
> >
> > Matt Liotta wrote:
> > > Actually I wasn't volunteering, but if no one else is working on
it
> then
> > > my company will likely tackle the problem in the coming months. I
> just
> > > didn't want to waste resources on work someone else was doing.
> > >
> >
> > That would be cool. However, I'm not dead sure that the Xerces
> > dependancy can be removed easily from the current codebase. I think
> that
> > some of the Xindice internals rely on some Xerces code (not exposed
by
> > Jaxp). This is for sure the case with Xalan, on which the source
> relies
> > for the XPath compiler (and, BTW, XUpdate too depends on Xalan).
> >
> > > BTW, any Xindice hackers out there who are looking for contract
work
> > > implementing changes to Xindice?
> >
> > Oh well... you have my e-mail, don't you? ;-)
> >
> > Ciao,
> >
> > --
> > Gianugo Rabellino
> > CTO
> > Pro-netics s.r.l.
> > http://www.pro-netics.com
RE: Xerces dependency
Posted by Lixin Meng <lx...@yahoo.com>.
I also did a test that removing the xerces???.jar from xml-xindice/java/lib
directory. It doesn't seem affect the build nor basic query (I didn't test
the RPC staff though).
Is this because I am using j2sdk1.4.1, which already has xerces? If the
problem Kevin mentioned solved, will it still be necessary for Xindice to be
shipped with Xerces???.jar?
Regards,
Lixin
-----Original Message-----
From: Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
Sent: Friday, February 14, 2003 11:43 AM
To: xindice-dev@xml.apache.org
Subject: RE: Xerces dependency
The dependency I found seems to lie in the XmlRpc.setDriver("xerces")
scattered throughout.
It seems that (http://ws.apache.org/xmlrpc/parser.html) you should be
able to change that easily, by making this configurable (xindice config)
and using the configured implementation in the code.
Just my thoughts from a little perusing...
-Kevin Ross
-----Original Message-----
From: Matt Liotta [mailto:mliotta@r337.com]
Sent: Friday, February 14, 2003 12:27 PM
To: xindice-dev@xml.apache.org
Subject: RE: Xerces dependency
I believe I remember seeing comments in the code about the dependency
thus implying to me at least that removal of the dependency would be
non-trivial. However, we have found a business need to remove the Xerces
dependency and figured the project could benefit.
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
> -----Original Message-----
> From: Gianugo Rabellino [mailto:gianugo@apache.org]
> Sent: Friday, February 14, 2003 12:47 PM
> To: xindice-dev@xml.apache.org
> Subject: Re: Xerces dependency
>
> Matt Liotta wrote:
> > Actually I wasn't volunteering, but if no one else is working on it
then
> > my company will likely tackle the problem in the coming months. I
just
> > didn't want to waste resources on work someone else was doing.
> >
>
> That would be cool. However, I'm not dead sure that the Xerces
> dependancy can be removed easily from the current codebase. I think
that
> some of the Xindice internals rely on some Xerces code (not exposed by
> Jaxp). This is for sure the case with Xalan, on which the source
relies
> for the XPath compiler (and, BTW, XUpdate too depends on Xalan).
>
> > BTW, any Xindice hackers out there who are looking for contract work
> > implementing changes to Xindice?
>
> Oh well... you have my e-mail, don't you? ;-)
>
> Ciao,
>
> --
> Gianugo Rabellino
> CTO
> Pro-netics s.r.l.
> http://www.pro-netics.com
RE: Xerces dependency
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
The dependency I found seems to lie in the XmlRpc.setDriver("xerces")
scattered throughout.
It seems that (http://ws.apache.org/xmlrpc/parser.html) you should be
able to change that easily, by making this configurable (xindice config)
and using the configured implementation in the code.
Just my thoughts from a little perusing...
-Kevin Ross
-----Original Message-----
From: Matt Liotta [mailto:mliotta@r337.com]
Sent: Friday, February 14, 2003 12:27 PM
To: xindice-dev@xml.apache.org
Subject: RE: Xerces dependency
I believe I remember seeing comments in the code about the dependency
thus implying to me at least that removal of the dependency would be
non-trivial. However, we have found a business need to remove the Xerces
dependency and figured the project could benefit.
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
> -----Original Message-----
> From: Gianugo Rabellino [mailto:gianugo@apache.org]
> Sent: Friday, February 14, 2003 12:47 PM
> To: xindice-dev@xml.apache.org
> Subject: Re: Xerces dependency
>
> Matt Liotta wrote:
> > Actually I wasn't volunteering, but if no one else is working on it
then
> > my company will likely tackle the problem in the coming months. I
just
> > didn't want to waste resources on work someone else was doing.
> >
>
> That would be cool. However, I'm not dead sure that the Xerces
> dependancy can be removed easily from the current codebase. I think
that
> some of the Xindice internals rely on some Xerces code (not exposed by
> Jaxp). This is for sure the case with Xalan, on which the source
relies
> for the XPath compiler (and, BTW, XUpdate too depends on Xalan).
>
> > BTW, any Xindice hackers out there who are looking for contract work
> > implementing changes to Xindice?
>
> Oh well... you have my e-mail, don't you? ;-)
>
> Ciao,
>
> --
> Gianugo Rabellino
> CTO
> Pro-netics s.r.l.
> http://www.pro-netics.com
RE: Xerces dependency
Posted by Matt Liotta <ml...@r337.com>.
I believe I remember seeing comments in the code about the dependency
thus implying to me at least that removal of the dependency would be
non-trivial. However, we have found a business need to remove the Xerces
dependency and figured the project could benefit.
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
> -----Original Message-----
> From: Gianugo Rabellino [mailto:gianugo@apache.org]
> Sent: Friday, February 14, 2003 12:47 PM
> To: xindice-dev@xml.apache.org
> Subject: Re: Xerces dependency
>
> Matt Liotta wrote:
> > Actually I wasn't volunteering, but if no one else is working on it
then
> > my company will likely tackle the problem in the coming months. I
just
> > didn't want to waste resources on work someone else was doing.
> >
>
> That would be cool. However, I'm not dead sure that the Xerces
> dependancy can be removed easily from the current codebase. I think
that
> some of the Xindice internals rely on some Xerces code (not exposed by
> Jaxp). This is for sure the case with Xalan, on which the source
relies
> for the XPath compiler (and, BTW, XUpdate too depends on Xalan).
>
> > BTW, any Xindice hackers out there who are looking for contract work
> > implementing changes to Xindice?
>
> Oh well... you have my e-mail, don't you? ;-)
>
> Ciao,
>
> --
> Gianugo Rabellino
> CTO
> Pro-netics s.r.l.
> http://www.pro-netics.com
Re: Xerces dependency
Posted by Gianugo Rabellino <gi...@apache.org>.
Matt Liotta wrote:
> Actually I wasn't volunteering, but if no one else is working on it then
> my company will likely tackle the problem in the coming months. I just
> didn't want to waste resources on work someone else was doing.
>
That would be cool. However, I'm not dead sure that the Xerces
dependancy can be removed easily from the current codebase. I think that
some of the Xindice internals rely on some Xerces code (not exposed by
Jaxp). This is for sure the case with Xalan, on which the source relies
for the XPath compiler (and, BTW, XUpdate too depends on Xalan).
> BTW, any Xindice hackers out there who are looking for contract work
> implementing changes to Xindice?
Oh well... you have my e-mail, don't you? ;-)
Ciao,
--
Gianugo Rabellino
CTO
Pro-netics s.r.l.
http://www.pro-netics.com
Re: Xerces dependency
Posted by Gary Shea <sh...@gtsdesign.com>.
I'm just reading the internals guide and just wanted to say "thanks!" to
James Bates. Very very useful. Kinda fun too, as I'm teaching an
overview data structures class at our local java user's group, and last
weeks topic was trees!
Gary
Re: Xerces dependency
Posted by Gary Shea <sh...@gtsdesign.com>.
On Mon, 24 Feb 2003, at 00:38 [-0800], Vladimir R. Bossicard...:
> Nice work. And I'm glad to see that the tests have been patched :-)
Thanks!
I'm a believer when it comes to test-first, although not always so good
at the practice. There's clearly been a lot of hard work put into the
tests, it was a big help.
> > Added three properties to the build.properties file:
> > test.xmlrpc.driver (SAX driver)
> > test.xmlrpc.hostport (host:port)
> > test.xmlrpc.service-location (/Xindice/ or whatever)
>
> I will use the PropertyManager class to handle the properties (class in
> the JUnit-addons package). The properties will then be located in an
> external file so that you can modify them without affecting the build.
So something like 'test.properties'?
Gary
>
> -Vladimir
>
> --
> Vladimir R. Bossicard
> Apache Xindice - http://xml.apache.org/xindice
>
>
>
Re: Xerces dependency
Posted by "Vladimir R. Bossicard" <vl...@apache.org>.
Nice work. And I'm glad to see that the tests have been patched :-)
> Added three properties to the build.properties file:
> test.xmlrpc.driver (SAX driver)
> test.xmlrpc.hostport (host:port)
> test.xmlrpc.service-location (/Xindice/ or whatever)
I will use the PropertyManager class to handle the properties (class in
the JUnit-addons package). The properties will then be located in an
external file so that you can modify them without affecting the build.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice
Re: Xerces dependency
Posted by Gary Shea <sh...@gtsdesign.com>.
Finally got it all working and tested. The things I needed to do in
order to get it working were:
XindiceServlet looks in the system.xml file for the parser to use on
the server side.
xmlrpc.DatabaseImpl supports an "xmlrpc-driver" property through its
Configurable interface. This is tricky because the user interacts
with the client.DatabaseImpl class, which lazily creates the
xmlrpc.DatabaseImpl, so the user never gets a chance to see the
xmlrpc.DatabaseImpl class and call its setProperty() method. I
dealt with that by having the xmlrpc.DatabaseImpl configuration be a
clone of the client.DatabaseImpl configuration. The user remains
unaware that there are three DatabaseImpl classes.
xmlrpc.CollectionImpl takes an xmlrpcDriver argument to the
constructor. It uses (in order of declining priority):
the xmlrpcDriver value (if non-null),
the xindice.xmlrpc.driver System property (if non-null)
the local default (currently "xindice")
IntegrationXmlRpcTests looks for a test.xmlrpc.driver system
property and uses it to set a property on the Database object.
Also ran into a variety of inconveniences while learning my way around
the package, and made some changes to allow more flexible configuration
of the XML-RPC client. Some of the test-related changes may be
obsoleted by Vladimir's upcoming Jetty work.
XmlDbClient (in the tests) was throwing NPEs if the tomcat server
wasn't running. Now throws a XindiceException with a semi-helpful
message instead.
xmlrpc.DatabaseImpl supports a "service-location" property through its
Configurable interface. The service location specifies the path to
the XML-RPC service on the web server.
xmlrpc.CollectionImpl takes an serviceLocation argument to the
constructor. It uses (in order of declining priority):
the serviceLocation value (if non-null),
the xindice.xmlrpc.service-location System property (if non-null)
the local default (currently "/Xindice/")
Added three properties to the build.properties file:
test.xmlrpc.driver (SAX driver)
test.xmlrpc.hostport (host:port)
test.xmlrpc.service-location (/Xindice/ or whatever)
Modified the test-integration-xmlrpc target to use <java> instead
of <junit> so that exceptions get reported properly; added the three
test.* properties.
IntegrationXmlRpcTests looks for a test.xmlrpc.service-location
system property. property and uses it to set a property on the
Database object.
All this stuff works nicely. The CollectionImpl and XindiceServlet are
hard to test so there are no unit tests for those changes.
Attached find the (tested!) patches.
Gary
Re: Xerces dependency
Posted by Gary Shea <sh...@gtsdesign.com>.
I took a second look at the system.xml file and where it gets loaded,
and that is indeed a better way.
I didn't do anything specific to work towards Dave Viner's comments
about configuring the XmlRpc messages, but elements I added should
permit those changes no problem:
<xindice>
...
<xml-rpc>
<driver name="..." />
...other xml-rpc configs...
</xml-rpc>
</xindice>
Attached find another untested patch. It's pretty ugly, the indentation
in that file is a mess. I am having trouble getting the
xmlrpc integration tests working, they error out with an NPE deep in
JUnit (error at the bottom of this email). I dunno what it is yet. The
unit and embedded integration tests work fine...
I have been looking at what it would take to write a unit test for the
XindiceServlet change, looks like I'd need to create/destroy a directory
in which to put a generated system.xml file. I've got a utility for
doing that... if you like I can donated it and add it to the test
heirarchy. Or, if anyone has a better idea how to run
servlet.init(ServletConfig) without going through all that, please let
me know...
Gary
The test was run against java 1.4.1 on linux.
------- junit failure in 'bin/ant test-integration-xmlrpc ------
Buildfile: build.xml
ZoneInfo: /usr/local/java/lib/zi/ZoneInfoMappings (No such file or
directory)
ZoneInfo: /usr/local/java/lib/zi/ZoneInfoMappings (No such file or
directory)
init:
src-build:
test-build:
test-validate:
[testClassValidator] TestClassValidator, by Vladimir R. Bossicard
[testClassValidator] Number of classes: 15
test-integration-xmlrpc:
[junit] Running org.apache.xindice.IntegrationXmlRpcTests
[junit] Exception in thread "main" java.lang.NullPointerException
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.PlainJUnitResultFormatter.endTest(PlainJUnitResultFormatter.java:208)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.PlainJUnitResultFormatter.formatError(PlainJUnitResultFormatter.java:245)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.PlainJUnitResultFormatter.addError(PlainJUnitResultFormatter.java:239)
[junit] at
junit.framework.TestResult.addError(TestResult.java:36)
[junit] at
junit.framework.TestResult.runProtected(TestResult.java:133)
[junit] at junitx.extensions.TestSetup.run(TestSetup.java:87)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:524)
[junit] TEST org.apache.xindice.IntegrationXmlRpcTests FAILED
BUILD SUCCESSFUL
Total time: 7 seconds
---------------------------------------------------------
On Wed, 19 Feb 2003, at 21:25 [-0700], Kimbro Staken (kstaken@xmldatabases....:
> Did you look into using the existing Configurable system to pick up the
> setting from system.xml instead of adding a separate Properties object?
> I don't know if it will work or not, but if it does that's how it
> should be done.
>
> On Monday, February 17, 2003, at 10:09 PM, Gary Shea wrote:
>
> > I've been looking over how to configure the xml-rpc sax parser, which
> > is
> > now hard-configured to 'xerces'.
[snip...]
RE: Xerces dependency
Posted by Dave Viner <dv...@yahoo-inc.com>.
we briefly discussed a related topic earlier. Look for messages from
12/05/2002 entitled "xml-rpc messages". I think it would be worth it to
configure not only the xml parser, but also the xmlrpc messages.
dave
-----Original Message-----
From: Gary Shea [mailto:shea@gtsdesign.com]
Sent: Wednesday, February 19, 2003 9:59 PM
To: xindice-dev@xml.apache.org
Subject: Re: Xerces dependency
Glanced at it, didn't really see what its intended scope was, forgot
about it ;) I'll take a closer look Thursday or Friday. Thanks for the
hint!
Gary
On Wed, 19 Feb 2003, at 21:25 [-0700], Kimbro Staken
(kstaken@xmldatabases....:
> Did you look into using the existing Configurable system to pick up the
> setting from system.xml instead of adding a separate Properties object?
> I don't know if it will work or not, but if it does that's how it
> should be done.
>
> On Monday, February 17, 2003, at 10:09 PM, Gary Shea wrote:
>
> > I've been looking over how to configure the xml-rpc sax parser, which
> > is
> > now hard-configured to 'xerces'.
> >
> > There are a few different places where it comes up:
> >
> > org.apache.xindice.client.xmldb.xmlrpc.CollectionImpl
> >
> > - DatabaseImpl is Configurable; set a property on DatabaseImpl,
> > export it to CollectionImpl.
> >
> > org.apache.xindice.server.XindiceServlet
> >
> > - Use the web.xml file to set a property that can be accessed via
> > the ServletContext during init().
> >
> > org.apache.xindice.admin.XindiceAdmin
> > org.apache.xindice.client.xmldb.xmlrpcssl.CollectionImpl
> >
> > - in the scratchpad directory... does anybody care?
> >
> >
> > Untried patches attached for CollectionImpl and XindiceServlet. Let me
> > know if this is a satisfactory approach and I'll write tests and so
> > on...
> >
> > Gary
> >
> > On Fri, 14 Feb 2003, at 08:34 [-0500], Matt Liotta (mliotta@r337.com)
> > wrote:
> >
> >> Actually I wasn't volunteering, but if no one else is working on it
> >> then
> >> my company will likely tackle the problem in the coming months. I just
> >> didn't want to waste resources on work someone else was doing.
> >>
> >> BTW, any Xindice hackers out there who are looking for contract work
> >> implementing changes to Xindice?
> >>
> >> Matt Liotta
> >> President & CEO
> >> Montara Software, Inc.
> >> http://www.montarasoftware.com/
> >> 888-408-0900 x901
> >>
> >>> -----Original Message-----
> >>> From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
> >>> Sent: Friday, February 14, 2003 8:24 AM
> >>> To: xindice-dev@xml.apache.org
> >>> Subject: Re: Xerces dependency
> >>>
> >>>> Any plans to remove the Xerces dependency from Xindice and support
> >> JAXP
> >>>> instead?
> >>>
> >>> Thank you for volunteering :-)
> >>>
> >>> I'm not aware of any plan but if JAXP is smaller, faster you have my
> >> +1.
> >>>
> >>> -Vladimir
> >>>
> >>> --
> >>> Vladimir R. Bossicard
> >>> Apache Xindice - http://xml.apache.org/xindice
> >>
> >>
> > <xindice-xmlrpc.patch>
> Kimbro Staken
> Java and XML Software, Consulting and Writing
> http://www.xmldatabases.org/
> Apache Xindice native XML database http://xml.apache.org/xindice
> XML:DB Initiative http://www.xmldb.org
>
>
>
Re: Xerces dependency
Posted by Gary Shea <sh...@gtsdesign.com>.
Glanced at it, didn't really see what its intended scope was, forgot
about it ;) I'll take a closer look Thursday or Friday. Thanks for the
hint!
Gary
On Wed, 19 Feb 2003, at 21:25 [-0700], Kimbro Staken (kstaken@xmldatabases....:
> Did you look into using the existing Configurable system to pick up the
> setting from system.xml instead of adding a separate Properties object?
> I don't know if it will work or not, but if it does that's how it
> should be done.
>
> On Monday, February 17, 2003, at 10:09 PM, Gary Shea wrote:
>
> > I've been looking over how to configure the xml-rpc sax parser, which
> > is
> > now hard-configured to 'xerces'.
> >
> > There are a few different places where it comes up:
> >
> > org.apache.xindice.client.xmldb.xmlrpc.CollectionImpl
> >
> > - DatabaseImpl is Configurable; set a property on DatabaseImpl,
> > export it to CollectionImpl.
> >
> > org.apache.xindice.server.XindiceServlet
> >
> > - Use the web.xml file to set a property that can be accessed via
> > the ServletContext during init().
> >
> > org.apache.xindice.admin.XindiceAdmin
> > org.apache.xindice.client.xmldb.xmlrpcssl.CollectionImpl
> >
> > - in the scratchpad directory... does anybody care?
> >
> >
> > Untried patches attached for CollectionImpl and XindiceServlet. Let me
> > know if this is a satisfactory approach and I'll write tests and so
> > on...
> >
> > Gary
> >
> > On Fri, 14 Feb 2003, at 08:34 [-0500], Matt Liotta (mliotta@r337.com)
> > wrote:
> >
> >> Actually I wasn't volunteering, but if no one else is working on it
> >> then
> >> my company will likely tackle the problem in the coming months. I just
> >> didn't want to waste resources on work someone else was doing.
> >>
> >> BTW, any Xindice hackers out there who are looking for contract work
> >> implementing changes to Xindice?
> >>
> >> Matt Liotta
> >> President & CEO
> >> Montara Software, Inc.
> >> http://www.montarasoftware.com/
> >> 888-408-0900 x901
> >>
> >>> -----Original Message-----
> >>> From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
> >>> Sent: Friday, February 14, 2003 8:24 AM
> >>> To: xindice-dev@xml.apache.org
> >>> Subject: Re: Xerces dependency
> >>>
> >>>> Any plans to remove the Xerces dependency from Xindice and support
> >> JAXP
> >>>> instead?
> >>>
> >>> Thank you for volunteering :-)
> >>>
> >>> I'm not aware of any plan but if JAXP is smaller, faster you have my
> >> +1.
> >>>
> >>> -Vladimir
> >>>
> >>> --
> >>> Vladimir R. Bossicard
> >>> Apache Xindice - http://xml.apache.org/xindice
> >>
> >>
> > <xindice-xmlrpc.patch>
> Kimbro Staken
> Java and XML Software, Consulting and Writing
> http://www.xmldatabases.org/
> Apache Xindice native XML database http://xml.apache.org/xindice
> XML:DB Initiative http://www.xmldb.org
>
>
>
Re: Xerces dependency
Posted by Kimbro Staken <ks...@xmldatabases.org>.
Did you look into using the existing Configurable system to pick up the
setting from system.xml instead of adding a separate Properties object?
I don't know if it will work or not, but if it does that's how it
should be done.
On Monday, February 17, 2003, at 10:09 PM, Gary Shea wrote:
> I've been looking over how to configure the xml-rpc sax parser, which
> is
> now hard-configured to 'xerces'.
>
> There are a few different places where it comes up:
>
> org.apache.xindice.client.xmldb.xmlrpc.CollectionImpl
>
> - DatabaseImpl is Configurable; set a property on DatabaseImpl,
> export it to CollectionImpl.
>
> org.apache.xindice.server.XindiceServlet
>
> - Use the web.xml file to set a property that can be accessed via
> the ServletContext during init().
>
> org.apache.xindice.admin.XindiceAdmin
> org.apache.xindice.client.xmldb.xmlrpcssl.CollectionImpl
>
> - in the scratchpad directory... does anybody care?
>
>
> Untried patches attached for CollectionImpl and XindiceServlet. Let me
> know if this is a satisfactory approach and I'll write tests and so
> on...
>
> Gary
>
> On Fri, 14 Feb 2003, at 08:34 [-0500], Matt Liotta (mliotta@r337.com)
> wrote:
>
>> Actually I wasn't volunteering, but if no one else is working on it
>> then
>> my company will likely tackle the problem in the coming months. I just
>> didn't want to waste resources on work someone else was doing.
>>
>> BTW, any Xindice hackers out there who are looking for contract work
>> implementing changes to Xindice?
>>
>> Matt Liotta
>> President & CEO
>> Montara Software, Inc.
>> http://www.montarasoftware.com/
>> 888-408-0900 x901
>>
>>> -----Original Message-----
>>> From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
>>> Sent: Friday, February 14, 2003 8:24 AM
>>> To: xindice-dev@xml.apache.org
>>> Subject: Re: Xerces dependency
>>>
>>>> Any plans to remove the Xerces dependency from Xindice and support
>> JAXP
>>>> instead?
>>>
>>> Thank you for volunteering :-)
>>>
>>> I'm not aware of any plan but if JAXP is smaller, faster you have my
>> +1.
>>>
>>> -Vladimir
>>>
>>> --
>>> Vladimir R. Bossicard
>>> Apache Xindice - http://xml.apache.org/xindice
>>
>>
> <xindice-xmlrpc.patch>
Kimbro Staken
Java and XML Software, Consulting and Writing
http://www.xmldatabases.org/
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
RE: Xerces dependency
Posted by Gary Shea <sh...@gtsdesign.com>.
I've been looking over how to configure the xml-rpc sax parser, which is
now hard-configured to 'xerces'.
There are a few different places where it comes up:
org.apache.xindice.client.xmldb.xmlrpc.CollectionImpl
- DatabaseImpl is Configurable; set a property on DatabaseImpl,
export it to CollectionImpl.
org.apache.xindice.server.XindiceServlet
- Use the web.xml file to set a property that can be accessed via
the ServletContext during init().
org.apache.xindice.admin.XindiceAdmin
org.apache.xindice.client.xmldb.xmlrpcssl.CollectionImpl
- in the scratchpad directory... does anybody care?
Untried patches attached for CollectionImpl and XindiceServlet. Let me
know if this is a satisfactory approach and I'll write tests and so
on...
Gary
On Fri, 14 Feb 2003, at 08:34 [-0500], Matt Liotta (mliotta@r337.com) wrote:
> Actually I wasn't volunteering, but if no one else is working on it then
> my company will likely tackle the problem in the coming months. I just
> didn't want to waste resources on work someone else was doing.
>
> BTW, any Xindice hackers out there who are looking for contract work
> implementing changes to Xindice?
>
> Matt Liotta
> President & CEO
> Montara Software, Inc.
> http://www.montarasoftware.com/
> 888-408-0900 x901
>
> > -----Original Message-----
> > From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
> > Sent: Friday, February 14, 2003 8:24 AM
> > To: xindice-dev@xml.apache.org
> > Subject: Re: Xerces dependency
> >
> > > Any plans to remove the Xerces dependency from Xindice and support
> JAXP
> > > instead?
> >
> > Thank you for volunteering :-)
> >
> > I'm not aware of any plan but if JAXP is smaller, faster you have my
> +1.
> >
> > -Vladimir
> >
> > --
> > Vladimir R. Bossicard
> > Apache Xindice - http://xml.apache.org/xindice
>
>
>
Re: Xerces dependency
Posted by Kimbro Staken <ks...@xmldatabases.org>.
On Friday, February 14, 2003, at 06:34 AM, Matt Liotta wrote:
> Actually I wasn't volunteering, but if no one else is working on it
> then
> my company will likely tackle the problem in the coming months. I just
> didn't want to waste resources on work someone else was doing.
This should be relatively simple. The actual database core is already
independent of Xerces, it's just the XML-RPC layer that needs it, or
rather needs a UTF-8 capable XML parser (the default used by Apache
XML-RPC is not). It just needs to be made configurable.
>
> BTW, any Xindice hackers out there who are looking for contract work
> implementing changes to Xindice?
I'm always willing to discuss, though my availability is somewhat
limited right now.
>
> Matt Liotta
> President & CEO
> Montara Software, Inc.
> http://www.montarasoftware.com/
> 888-408-0900 x901
>
>> -----Original Message-----
>> From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
>> Sent: Friday, February 14, 2003 8:24 AM
>> To: xindice-dev@xml.apache.org
>> Subject: Re: Xerces dependency
>>
>>> Any plans to remove the Xerces dependency from Xindice and support
> JAXP
>>> instead?
>>
>> Thank you for volunteering :-)
>>
>> I'm not aware of any plan but if JAXP is smaller, faster you have my
> +1.
>>
>> -Vladimir
>>
>> --
>> Vladimir R. Bossicard
>> Apache Xindice - http://xml.apache.org/xindice
>
>
Kimbro Staken
Java and XML Software, Consulting and Writing
http://www.xmldatabases.org/
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
RE: Xerces dependency
Posted by Matt Liotta <ml...@r337.com>.
Actually I wasn't volunteering, but if no one else is working on it then
my company will likely tackle the problem in the coming months. I just
didn't want to waste resources on work someone else was doing.
BTW, any Xindice hackers out there who are looking for contract work
implementing changes to Xindice?
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
> -----Original Message-----
> From: Vladimir R. Bossicard [mailto:vladimir@apache.org]
> Sent: Friday, February 14, 2003 8:24 AM
> To: xindice-dev@xml.apache.org
> Subject: Re: Xerces dependency
>
> > Any plans to remove the Xerces dependency from Xindice and support
JAXP
> > instead?
>
> Thank you for volunteering :-)
>
> I'm not aware of any plan but if JAXP is smaller, faster you have my
+1.
>
> -Vladimir
>
> --
> Vladimir R. Bossicard
> Apache Xindice - http://xml.apache.org/xindice
Re: Xerces dependency
Posted by "Vladimir R. Bossicard" <vl...@apache.org>.
> Any plans to remove the Xerces dependency from Xindice and support JAXP
> instead?
Thank you for volunteering :-)
I'm not aware of any plan but if JAXP is smaller, faster you have my +1.
-Vladimir
--
Vladimir R. Bossicard
Apache Xindice - http://xml.apache.org/xindice