You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-users@xml.apache.org by David Kensche <da...@rwth-aachen.de> on 2003/12/17 18:48:06 UTC
Problem with upgrade from 1.0
Hi,
I'm just replacing my old xindice 1.0 with the newest version from cvs.
After moving
some jars hence and forth, this is the farest I get with my own application:
[java] 2003-12-17 18:44:11,014 80 [AWT-EventQueue-0] DEBUG
repository.XindiceRepositoryManager - Driver loaded.
[java] 2003-12-17 18:44:11,024 90 [AWT-EventQueue-0] DEBUG
repository.XindiceRepositoryManager - DB registered.
[java] 2003-12-17 18:44:11,024 90 [AWT-EventQueue-0] DEBUG
repository.XindiceRepositoryManager -
rootCollection=xmldb:xindice-embed://localhost:8080/db/MonA
[java] 2003-12-17 18:39:47,105 291 [AWT-EventQueue-0] INFO
org.apache.xindice.client.xmldb.embed.DatabaseImpl - No configuration
file specified, going with the default configuration
[java] 2003-12-17 18:39:47,125 311 [AWT-EventQueue-0] WARN
org.apache.xindice.xml.dom.DOMParser - ignored exception
[java] org.xml.sax.SAXNotSupportedException: Feature:
http://xml.org/sax/features/external-general-entities
[java] at
org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:211)
[java] at
org.apache.xindice.xml.dom.DOMParser.setReaderFeature(DOMParser.java:237)
[java] at
org.apache.xindice.xml.dom.DOMParser.getSAXParser(DOMParser.java:252)
[java] at
org.apache.xindice.xml.dom.DOMParser.<init>(DOMParser.java:112)
[java] at
org.apache.xindice.xml.dom.DOMParser.toDocument(DOMParser.java:210)
[java] at
org.apache.xindice.client.xmldb.embed.DatabaseImpl.loadConfiguration(DatabaseImpl.java:186)
[java] at
org.apache.xindice.client.xmldb.embed.DatabaseImpl.init(DatabaseImpl.java:145)
[java] at
org.apache.xindice.client.xmldb.embed.DatabaseImpl.<init>(DatabaseImpl.java:130)
[java] at
org.apache.xindice.client.xmldb.DatabaseImpl.createDriver(DatabaseImpl.java:216)
[java] at
org.apache.xindice.client.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:158)
[java] at org.xmldb.api.DatabaseManager.getCollection(Unknown
Source)
[java] at org.xmldb.api.DatabaseManager.getCollection(Unknown
Source)
[java] at
repository.XindiceRepositoryManager.createRepository(XindiceRepositoryManager.java:52)
[java] at
ui.MonAUIImportDialog$3.actionPerformed(MonAUIImportDialog.java:207)
[java] at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1764)
This is my code:
String driver = "org.apache.xindice.client.xmldb.DatabaseImpl";
Class c = Class.forName(driver);
// Get the database interface from the driver. This is the concrete
// Database implementation provided by xindice conforming the
// XML:DB Database API.
logger.debug("Loading driver.");
Database database = (Database)c.newInstance();
logger.debug("Driver loaded.");
// Register this database-driver to the concrete DB Manager of the
XML:DB API
DatabaseManager.registerDatabase(database);
logger.debug("DB registered.");
rootCollection = "xmldb:xindice-embed://"+
((host != null)?host:"localhost")+":"+
((port != null)?port:"4080")+"/"+
((db != null)?db:"db")+"/MonA";
logger.debug("rootCollection="+rootCollection);
Collection col = DatabaseManager.getCollection(rootCollection);
Does anybody know, how to fix this exception? The last line creates the
exception.
The collection exists. I created it via command line.
And: where do I have to put which configuration file when I don't want
the db in
my working directory?
Thanks beforehand,
David
--
David Kensche
Rethelstr. 2
52062 Aachen
Tel.: 0241/4019185
Re: collection's disapper?!
Posted by Upayavira <uv...@upaya.co.uk>.
David Kensche wrote:
> Vadim Gritsenko wrote:
>
>> David Kensche wrote:
>>
>>> Hi,
>>> I upgraded from 1.0 to 1.1. When I restart the servlet engine, all
>>> collections, which I
>>> created have disappeared. They are yet present on the filesystem,
>>> but for client's they
>>> are not visible. Does anyone know what's wrong?
>>
>>
>>
>>
>> Are you sure that these versions use same configuration file format,
>> and same file format? Do you have config.xml similar to what is in
>> xindice 1.1?
>>
>> (sorry for asking you questions - I have not worked with 1.0)
>
>
> On 1.0 I don't have any config.xml and I must admit that I didn't
> think about checking its content
> on 1.1. But since I'm now fighting against 1.1 for several days,
> blocking my work, and just recognized,
> that xpath expressions of my application (...[@dfsVisit>=..] ) which
> worked on 1.0 don't work
> anymore, I decided to stay with 1.0 until 1.1 is a little easier to
> use. I'm kind of frustrated :-(
Try the CVS version, rather than 1.1b1. You'll find it _much_ better.
Regards, Upayavira
Re: collection's disapper?!
Posted by Vadim Gritsenko <va...@verizon.net>.
David Kensche wrote:
> Upayavira wrote:
...
>> Have you tried it without the webapp running? Just to test whether we
>> are talking about the same problem?
>>
>> Regards, Upayavira
>
>
> You were right.
> As I said there are two contexts running on tomcat - xindice-1.1b3-dev
> and xindice. The tools and my applications
> always access the xindice context.
David,
Please take a look at:
http://xml.apache.org/xindice/dev/guide-developer.html
http://xml.apache.org/xindice/dev/guide-administrator.html
Search for "context" word. If something is not complete or not clear,
please don't mind writing one or two paragraphs which you think should
be included into the documentation.
> When I stop xindice-1.1b3-dev before making any changes to the
> database, the
> changes persist. Why are there two contexts at all?
I guess because you have deployed two web applications. Web application
can be deployed either:
(a) By copying war file or webapp directory under the webapp folder
(b) By placing *.xml file under the webapp folder, and this xml should
refer to war file or webapp directory
> And why one, which is not accessed by the tools?
Answer on this is in the docs: all tools default to "/xindice" context.
It can be overridden by system property.
> And how can
> the xindice-1.1b3-dev context be running if it is is not accessed by
> any application?
Because you have started it. You can find more information about web
applications on Tomcat forums and in Sun's documentation.
Vadim
Re: collection's disapper?!
Posted by David Kensche <da...@rwth-aachen.de>.
Upayavira wrote:
> David Kensche wrote:
>
>> Upayavira wrote:
>>
>>>
>>> I have found that any changes to the database you make using the CLI
>>> will be lost if you are running another process that has connected
>>> to the database (servlet or embedded mode code). Stopping Tomcat,
>>> adding the collection/documents, and then restarting Tomcat, should
>>> work around this.
>>>
>>> Now, I don't know whether this should be considered a bug. Probably
>>> should. It would certainly be useful to me if I could add stuff from
>>> outside my servlet environment.
>>>
>>> Regards, Upayavira
>>
>>
>>
>> That's definitely the case. I have a webapplication running, which
>> reads an ontology from the db. Also I have a gui
>> running for access to the documents which are inserted by another
>> application. The problem is that at least two
>> of those have to be running at the same time.
>
>
> Have you tried it without the webapp running? Just to test whether we
> are talking about the same problem?
>
> Regards, Upayavira
You were right.
As I said there are two contexts running on tomcat - xindice-1.1b3-dev
and xindice. The tools and my applications
always access the xindice context. When I stop xindice-1.1b3-dev before
making any changes to the database, the
changes persist. Why are there two contexts at all? And why one, which
is not accessed by the tools? And how can
the xindice-1.1b3-dev context be running if it is is not accessed by any
application?
Regards,
David
Re: collection's disapper?!
Posted by Upayavira <uv...@upaya.co.uk>.
David Kensche wrote:
> Upayavira wrote:
>
>>
>> I have found that any changes to the database you make using the CLI
>> will be lost if you are running another process that has connected to
>> the database (servlet or embedded mode code). Stopping Tomcat, adding
>> the collection/documents, and then restarting Tomcat, should work
>> around this.
>>
>> Now, I don't know whether this should be considered a bug. Probably
>> should. It would certainly be useful to me if I could add stuff from
>> outside my servlet environment.
>>
>> Regards, Upayavira
>
>
> That's definitely the case. I have a webapplication running, which
> reads an ontology from the db. Also I have a gui
> running for access to the documents which are inserted by another
> application. The problem is that at least two
> of those have to be running at the same time.
Have you tried it without the webapp running? Just to test whether we
are talking about the same problem?
Regards, Upayavira
Re: collection's disapper?!
Posted by David Kensche <da...@rwth-aachen.de>.
Upayavira wrote:
>
> I have found that any changes to the database you make using the CLI
> will be lost if you are running another process that has connected to
> the database (servlet or embedded mode code). Stopping Tomcat, adding
> the collection/documents, and then restarting Tomcat, should work
> around this.
>
> Now, I don't know whether this should be considered a bug. Probably
> should. It would certainly be useful to me if I could add stuff from
> outside my servlet environment.
>
> Regards, Upayavira
That's definitely the case. I have a webapplication running, which reads
an ontology from the db. Also I have a gui
running for access to the documents which are inserted by another
application. The problem is that at least two
of those have to be running at the same time.
Thank you,
David
Re: collection's disapper?!
Posted by Vadim Gritsenko <va...@verizon.net>.
Upayavira wrote:
> Vadim Gritsenko wrote:
>
>> Upayavira wrote:
>> ...
>>
>>> I have found that any changes to the database you make using the CLI
>>> will be lost if you are running another process that has connected
>>> to the database (servlet or embedded mode code). Stopping Tomcat,
>>> adding the collection/documents, and then restarting Tomcat, should
>>> work around this.
>>
>>
>>
>>
>> Now, how you are trying to access this database from the CLI? You
>> should be connecting to your Xindice instance running on the "remote"
>> (i.e. separate JVM) instance. Example:
>>
>> bin\xindice lc -c xmldb:xindice://localhost:8080/db/
>>
>> Or (which is the same because XML-RPC is the default driver):
>> bin\xindice lc -c /db
>>
>>
>>> Now, I don't know whether this should be considered a bug.
>>
>>
>>
>>
>> If you are trying to use same ./db from two xindice instances and it
>> does not complain - yes, it should be considered a bug. Ideally, it
>> should throw "Database already open by another xindice instance"
>> exception or something.
>
>
> I have been using the embedded-mode client, and doing:
> xindice lc -l -d <conf file> -c /db
>
> to access a local db. It works, but the collections and documents are
> not visible via the embedded mode driver, and will dissapear from view
> via the CLI when you restart the servlet container (within which the
> embedded driver is running).
It is actually good that it disappears. Only one process should be
allowed to modify the database.
Do you know how to prevent access to the file in the jdk1.3, or it's
only possible in 1.4? Active process should lock a file to prevent
corruption which will happen of other process messes up with it.
Vadim
Re: collection's disapper?!
Posted by Upayavira <uv...@upaya.co.uk>.
Vadim Gritsenko wrote:
> Upayavira wrote:
> ...
>
>> I have found that any changes to the database you make using the CLI
>> will be lost if you are running another process that has connected to
>> the database (servlet or embedded mode code). Stopping Tomcat, adding
>> the collection/documents, and then restarting Tomcat, should work
>> around this.
>
>
>
> Now, how you are trying to access this database from the CLI? You
> should be connecting to your Xindice instance running on the "remote"
> (i.e. separate JVM) instance. Example:
>
> bin\xindice lc -c xmldb:xindice://localhost:8080/db/
>
> Or (which is the same because XML-RPC is the default driver):
> bin\xindice lc -c /db
>
>
>> Now, I don't know whether this should be considered a bug.
>
>
>
> If you are trying to use same ./db from two xindice instances and it
> does not complain - yes, it should be considered a bug. Ideally, it
> should throw "Database already open by another xindice instance"
> exception or something.
I have been using the embedded-mode client, and doing:
xindice lc -l -d <conf file> -c /db
to access a local db. It works, but the collections and documents are
not visible via the embedded mode driver, and will dissapear from view
via the CLI when you restart the servlet container (within which the
embedded driver is running).
Regards, Upayavira
Re: collection's disapper?!
Posted by Julien Le Dem <ju...@thet-is.com>.
I confirm the bug. You can access the database with several instances of
Xindice embed-mode. It leads to strange behaviour where I have not seen yet
a predictable pattern (like not seeing documents that have been added by
whatever of the instances). You never have an exception saying that several
process access the same db files.
It's usefull for debugging and tests to be able to view/modify the database
while accessed in embed mode, but I see no reasonable way of having it
working. I suppose that this possibility that can lead to incoherent data in
the file will be shut down by Xindice developpers. The solution to do such
things is to install Xindice as an independant server process (in Tomcat).
There you can access the database from different process on a rational way.
Julien.
----- Original Message -----
> If you are trying to use same ./db from two xindice instances and it
> does not complain - yes, it should be considered a bug. Ideally, it
> should throw "Database already open by another xindice instance"
> exception or something.
Re: collection's disapper?!
Posted by Vadim Gritsenko <va...@verizon.net>.
Upayavira wrote:
...
> I have found that any changes to the database you make using the CLI
> will be lost if you are running another process that has connected to
> the database (servlet or embedded mode code). Stopping Tomcat, adding
> the collection/documents, and then restarting Tomcat, should work
> around this.
Now, how you are trying to access this database from the CLI? You should
be connecting to your Xindice instance running on the "remote" (i.e.
separate JVM) instance. Example:
bin\xindice lc -c xmldb:xindice://localhost:8080/db/
Or (which is the same because XML-RPC is the default driver):
bin\xindice lc -c /db
> Now, I don't know whether this should be considered a bug.
If you are trying to use same ./db from two xindice instances and it
does not complain - yes, it should be considered a bug. Ideally, it
should throw "Database already open by another xindice instance"
exception or something.
Vadim
Re: collection's disapper?!
Posted by Upayavira <uv...@upaya.co.uk>.
David Kensche wrote:
>
>>>>
>>>>
>>>>
>>>>
>>>> Are you sure that these versions use same configuration file
>>>> format, and same file format? Do you have config.xml similar to
>>>> what is in xindice 1.1?
>>>>
>>>> (sorry for asking you questions - I have not worked with 1.0)
>>>
>>>
>>>
>>>
>>> On 1.0 I don't have any config.xml and I must admit that I didn't
>>> think about checking its content
>>> on 1.1. But since I'm now fighting against 1.1 for several days,
>>> blocking my work, and just recognized,
>>> that xpath expressions of my application (...[@dfsVisit>=..] ) which
>>> worked on 1.0 don't work
>>> anymore, I decided to stay with 1.0 until 1.1 is a little easier to
>>> use. I'm kind of frustrated :-(
>>
>>
>>
>>
>> Are you sure that you have latest version, and you have endorsed libs
>> issue resolved correctly?
>> If yes, then you have to submit a bug report. You can easily do so by
>> modifying test case XPathQueryResolverTest and running it.
>>
>> It came to me also, that if binary format is not compatible, then you
>> should be able to export from 1.0 and import content into 1.1 using
>> command line tools.
>>
>> Vadim
>
>
> Hi again,
> yes I use the version from cvs. But the xpath problem was a problem in
> my code.
> But the problem with the disappearing collections remains.
>
> I just tried to do everything from scratch. Maybe I did something
> wrong or forgot something:
>
> I set the XINDICE_HOME to be my cvs working directory I checked out to.
> I set my JAVA_ENDORSED_DIRS to %JAVA_HOME%\jre\lib\endorsed where I put
> xalan-2.5.2.jar, xerces-2.6.0.jar and xml-apis.jar.
>
> I checked out the latest version from cvs and executed the
> tomcat-deploy task. A directory
> ${TOMCAT_HOME}\webapps has been created with a war and an xml file in
> it (obviously
> my TOMCAT_HOME has not been recognized although set as environment
> variable).
>
> I copied both files to the webapps directory and started tomcat. Two
> contexts are now running:
> xindice and xindice-1.1b3-dev. I reckon it's both the same just with
> an alias, since there is no
> xindice directory in my webapps directory?
>
> I used the command line tool to create a collection:
> xindice ac -c xmldb:xindice://localhost:8080/db -n MonA
> which says: Collection created.
>
> I started my application with those two arguments, where ../lib is my
> application's lib dir containing the
> 3 jars above and some more.
> <jvmarg value="-Djavax.xml.parser.SAXParserFactory
> org.apache.xerces.jaxp.SAXParserFactory" />
> <jvmarg value="-Djava.endorsed.dirs ../lib" />
> and it seems to work, since according to logging the parser's
> classname, xerces is used.
>
> My application creates the collections like this (for example):
> col = DatabaseManager.getCollection(rootCollection);
> service = (CollectionManager)col.getService("CollectionManager",
> "1.0");
> collectionConfig =
> "<collection compressed=\"true\" name=\"" + domain + "\">" +
> " <filer class=\"org.apache.xindice.core.filer.BTreeFiler\"
> gzip=\"true\"/>" +
> "</collection>";
> service.createCollection(domain,
> DOMParser.toDocument(collectionConfig));
> with rootCollection = xmldb:xindice://localhost:8080/db/MonA
> domain = textile
>
> The command line tool as well as my application display all created
> collection's and documents correctly,
> but when I restart the database, everything is gone, although the
> collections are yet in the filesystem. No
> difference whether created via command line tool or my own code.
> The WEB-INF directory contains MonA/textile/documents with each of
> those directories containing a
> .tbl file and nothing more.
>
> Did I make any obvious mistake?
I have found that any changes to the database you make using the CLI
will be lost if you are running another process that has connected to
the database (servlet or embedded mode code). Stopping Tomcat, adding
the collection/documents, and then restarting Tomcat, should work around
this.
Now, I don't know whether this should be considered a bug. Probably
should. It would certainly be useful to me if I could add stuff from
outside my servlet environment.
Regards, Upayavira
Re: collection's disapper?!
Posted by David Kensche <da...@rwth-aachen.de>.
>>>
>>>
>>>
>>>
>>> Are you sure that these versions use same configuration file format,
>>> and same file format? Do you have config.xml similar to what is in
>>> xindice 1.1?
>>>
>>> (sorry for asking you questions - I have not worked with 1.0)
>>
>>
>>
>> On 1.0 I don't have any config.xml and I must admit that I didn't
>> think about checking its content
>> on 1.1. But since I'm now fighting against 1.1 for several days,
>> blocking my work, and just recognized,
>> that xpath expressions of my application (...[@dfsVisit>=..] ) which
>> worked on 1.0 don't work
>> anymore, I decided to stay with 1.0 until 1.1 is a little easier to
>> use. I'm kind of frustrated :-(
>
>
>
> Are you sure that you have latest version, and you have endorsed libs
> issue resolved correctly?
> If yes, then you have to submit a bug report. You can easily do so by
> modifying test case XPathQueryResolverTest and running it.
>
> It came to me also, that if binary format is not compatible, then you
> should be able to export from 1.0 and import content into 1.1 using
> command line tools.
>
> Vadim
Hi again,
yes I use the version from cvs. But the xpath problem was a problem in
my code.
But the problem with the disappearing collections remains.
I just tried to do everything from scratch. Maybe I did something wrong
or forgot something:
I set the XINDICE_HOME to be my cvs working directory I checked out to.
I set my JAVA_ENDORSED_DIRS to %JAVA_HOME%\jre\lib\endorsed where I put
xalan-2.5.2.jar, xerces-2.6.0.jar and xml-apis.jar.
I checked out the latest version from cvs and executed the tomcat-deploy
task. A directory
${TOMCAT_HOME}\webapps has been created with a war and an xml file in it
(obviously
my TOMCAT_HOME has not been recognized although set as environment
variable).
I copied both files to the webapps directory and started tomcat. Two
contexts are now running:
xindice and xindice-1.1b3-dev. I reckon it's both the same just with an
alias, since there is no
xindice directory in my webapps directory?
I used the command line tool to create a collection:
xindice ac -c xmldb:xindice://localhost:8080/db -n MonA
which says: Collection created.
I started my application with those two arguments, where ../lib is my
application's lib dir containing the
3 jars above and some more.
<jvmarg value="-Djavax.xml.parser.SAXParserFactory
org.apache.xerces.jaxp.SAXParserFactory" />
<jvmarg value="-Djava.endorsed.dirs ../lib" />
and it seems to work, since according to logging the parser's classname,
xerces is used.
My application creates the collections like this (for example):
col = DatabaseManager.getCollection(rootCollection);
service = (CollectionManager)col.getService("CollectionManager",
"1.0");
collectionConfig =
"<collection compressed=\"true\" name=\"" + domain + "\">" +
" <filer class=\"org.apache.xindice.core.filer.BTreeFiler\"
gzip=\"true\"/>" +
"</collection>";
service.createCollection(domain,
DOMParser.toDocument(collectionConfig));
with rootCollection = xmldb:xindice://localhost:8080/db/MonA
domain = textile
The command line tool as well as my application display all created
collection's and documents correctly,
but when I restart the database, everything is gone, although the
collections are yet in the filesystem. No
difference whether created via command line tool or my own code.
The WEB-INF directory contains MonA/textile/documents with each of those
directories containing a
.tbl file and nothing more.
Did I make any obvious mistake?
Thanks,
David
Re: collection's disapper?!
Posted by Vadim Gritsenko <va...@verizon.net>.
David Kensche wrote:
> Vadim Gritsenko wrote:
>
>> David Kensche wrote:
>>
>>> Hi,
>>> I upgraded from 1.0 to 1.1. When I restart the servlet engine, all
>>> collections, which I
>>> created have disappeared. They are yet present on the filesystem,
>>> but for client's they
>>> are not visible. Does anyone know what's wrong?
>>
>>
>>
>>
>> Are you sure that these versions use same configuration file format,
>> and same file format? Do you have config.xml similar to what is in
>> xindice 1.1?
>>
>> (sorry for asking you questions - I have not worked with 1.0)
>
>
> On 1.0 I don't have any config.xml and I must admit that I didn't
> think about checking its content
> on 1.1. But since I'm now fighting against 1.1 for several days,
> blocking my work, and just recognized,
> that xpath expressions of my application (...[@dfsVisit>=..] ) which
> worked on 1.0 don't work
> anymore, I decided to stay with 1.0 until 1.1 is a little easier to
> use. I'm kind of frustrated :-(
Are you sure that you have latest version, and you have endorsed libs
issue resolved correctly?
If yes, then you have to submit a bug report. You can easily do so by
modifying test case XPathQueryResolverTest and running it.
It came to me also, that if binary format is not compatible, then you
should be able to export from 1.0 and import content into 1.1 using
command line tools.
Vadim
Re: collection's disapper?!
Posted by David Kensche <da...@rwth-aachen.de>.
Vadim Gritsenko wrote:
> David Kensche wrote:
>
>> Hi,
>> I upgraded from 1.0 to 1.1. When I restart the servlet engine, all
>> collections, which I
>> created have disappeared. They are yet present on the filesystem, but
>> for client's they
>> are not visible. Does anyone know what's wrong?
>
>
>
> Are you sure that these versions use same configuration file format,
> and same file format? Do you have config.xml similar to what is in
> xindice 1.1?
>
> (sorry for asking you questions - I have not worked with 1.0)
On 1.0 I don't have any config.xml and I must admit that I didn't think
about checking its content
on 1.1. But since I'm now fighting against 1.1 for several days,
blocking my work, and just recognized,
that xpath expressions of my application (...[@dfsVisit>=..] ) which
worked on 1.0 don't work
anymore, I decided to stay with 1.0 until 1.1 is a little easier to use.
I'm kind of frustrated :-(
Thanks anyway,
David
Re: collection's disapper?!
Posted by Vadim Gritsenko <va...@verizon.net>.
David Kensche wrote:
> Hi,
> I upgraded from 1.0 to 1.1. When I restart the servlet engine, all
> collections, which I
> created have disappeared. They are yet present on the filesystem, but
> for client's they
> are not visible. Does anyone know what's wrong?
Are you sure that these versions use same configuration file format, and
same file format? Do you have config.xml similar to what is in xindice 1.1?
(sorry for asking you questions - I have not worked with 1.0)
Vadim
collection's disapper?!
Posted by David Kensche <da...@rwth-aachen.de>.
Hi,
I upgraded from 1.0 to 1.1. When I restart the servlet engine, all
collections, which I
created have disappeared. They are yet present on the filesystem, but
for client's they
are not visible. Does anyone know what's wrong?
Thanks beforehand,
David
Re: Problem with upgrade from 1.0
Posted by Vadim Gritsenko <va...@verizon.net>.
David Kensche wrote:
> Vadim Gritsenko wrote:
>
>>> [java] 2003-12-17 18:39:47,105 291 [AWT-EventQueue-0] INFO
>>> org.apache.xindice.client.xmldb.embed.DatabaseImpl - No
>>> configuration file specified, going with the default configuration
>>> [java] 2003-12-17 18:39:47,125 311 [AWT-EventQueue-0] WARN
>>> org.apache.xindice.xml.dom.DOMParser - ignored exception
>>> [java] org.xml.sax.SAXNotSupportedException: Feature:
>>> http://xml.org/sax/features/external-general-entities
>>> [java] at
>>> org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:211)
>>>
>>
>>
>>
>>
>> You are supposed to use xerces, and not crimson. Crimson is really
>> old XML parser which does not support a lot of features / standards.
>>
>> If you are using jdk1.4, this is easily done by specifying property
>> in command line:
>> -Djava.endorsed.dirs=<path to dir with xerces, xml-apis, xalan jars>
>>
>> You can see latest xindice CVS for an example of how this can be
>> achieved.
>
>
> Hm, I don't know Crimson, but I know I have xindice in my classpath
> and I start the program
> from an ant target, using only my application's lib directory and the
> rt.jar in the classpath.
(in addition to usual classpath, jdk1.4 has "endorsed libs path", which
preceeds classpath)
> Thus unless
> crimson is hidden in some of those jars, it can't be loaded. Know I
> started it
> with
> <jvmarg value="-Djava.endorsed.dirs=../lib" />
> which is my lib directory, so xerces (xerces-2.6.0.jar) should be in
> the path.
> This is my url:
> xmldb:xindice://localhost:8080/db/MonA
> But know the collection is null.
When you use xmldb:xindice:... url, you are trying to connect to remote
xindice server using xmlrpc protocol. I guess you have this server
running (because you do not get connection exception), but do you have
collection there created?
btw, if you do not see logs from the xindice, you can turn them on:
<jvmarg
value="-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog"/>
<jvmarg
value="-Dorg.apache.commons.logging.simplelog.defaultlog=debug"/>
May be they will provide you with some additional info.
Vadim
Re: Problem with upgrade from 1.0
Posted by David Kensche <da...@rwth-aachen.de>.
Vadim Gritsenko wrote:
>> [java] 2003-12-17 18:39:47,105 291 [AWT-EventQueue-0] INFO
>> org.apache.xindice.client.xmldb.embed.DatabaseImpl - No configuration
>> file specified, going with the default configuration
>> [java] 2003-12-17 18:39:47,125 311 [AWT-EventQueue-0] WARN
>> org.apache.xindice.xml.dom.DOMParser - ignored exception
>> [java] org.xml.sax.SAXNotSupportedException: Feature:
>> http://xml.org/sax/features/external-general-entities
>> [java] at
>> org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:211)
>>
>
>
>
> You are supposed to use xerces, and not crimson. Crimson is really old
> XML parser which does not support a lot of features / standards.
>
> If you are using jdk1.4, this is easily done by specifying property in
> command line:
> -Djava.endorsed.dirs=<path to dir with xerces, xml-apis, xalan jars>
>
> You can see latest xindice CVS for an example of how this can be
> achieved.
Hm, I don't know Crimson, but I know I have xindice in my classpath and
I start the program
from an ant target, using only my application's lib directory and the
rt.jar in the classpath. Thus unless
crimson is hidden in some of those jars, it can't be loaded. Know I
started it
with
<jvmarg value="-Djava.endorsed.dirs=../lib" />
which is my lib directory, so xerces (xerces-2.6.0.jar) should be in the
path.
This is my url:
xmldb:xindice://localhost:8080/db/MonA
But know the collection is null.
The code didn't change - apart from the url (xindice-embed -> xindice).
Those jars are in my classpath:
Tidy.jar
antlr.debug.jar
axis.jar
commons-discovery.jar
commons-logging-1.0.3.jar
googleapi.jar
icu4j.jar
jaxrpc.jar
jdom.jar
jena.jar
junit.jar
log4j-1.2.8.jar
org.apache.commons.jrcs.diff.jar
saaj.jar
servlet.jar
xalan-2.5.2.jar
xerces-2.6.0.jar
xindice-1.1b3-dev.jar
xml-apis.jar
xmldb-api-20021118.jar
xmldb-api-sdk-20021118.jar
xmldb-common.jar
xmldb-xupdate.jar
xmlrpc-1.1.jar
Is there something missing, or do you know about ambivalences?
Is this again the problem with the parser? Removing the jvmarg has the
same effect.
Again, thanks beforehand,
David
--
David Kensche
Rethelstr. 2
52062 Aachen
Tel.: 0241/4019185
Re: Problem with upgrade from 1.0
Posted by Vadim Gritsenko <va...@verizon.net>.
David Kensche wrote:
> Hi,
> I'm just replacing my old xindice 1.0 with the newest version from
> cvs. After moving
> some jars hence and forth, this is the farest I get with my own
> application:
>
> [java] 2003-12-17 18:44:11,014 80 [AWT-EventQueue-0] DEBUG
> repository.XindiceRepositoryManager - Driver loaded.
> [java] 2003-12-17 18:44:11,024 90 [AWT-EventQueue-0] DEBUG
> repository.XindiceRepositoryManager - DB registered.
> [java] 2003-12-17 18:44:11,024 90 [AWT-EventQueue-0] DEBUG
> repository.XindiceRepositoryManager -
> rootCollection=xmldb:xindice-embed://localhost:8080/db/MonA
If you use embedded driver, there is no sense in specifying host/port,
so url will be xmldb:xindice-embed:///db/MonA
> [java] 2003-12-17 18:39:47,105 291 [AWT-EventQueue-0] INFO
> org.apache.xindice.client.xmldb.embed.DatabaseImpl - No configuration
> file specified, going with the default configuration
> [java] 2003-12-17 18:39:47,125 311 [AWT-EventQueue-0] WARN
> org.apache.xindice.xml.dom.DOMParser - ignored exception
> [java] org.xml.sax.SAXNotSupportedException: Feature:
> http://xml.org/sax/features/external-general-entities
> [java] at
> org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:211)
>
You are supposed to use xerces, and not crimson. Crimson is really old
XML parser which does not support a lot of features / standards.
If you are using jdk1.4, this is easily done by specifying property in
command line:
-Djava.endorsed.dirs=<path to dir with xerces, xml-apis, xalan jars>
You can see latest xindice CVS for an example of how this can be achieved.
...
> This is my code:
> String driver = "org.apache.xindice.client.xmldb.DatabaseImpl";
> Class c = Class.forName(driver);
> // Get the database interface from the driver. This is the concrete
> // Database implementation provided by xindice conforming the
> // XML:DB Database API.
> logger.debug("Loading driver.");
> Database database = (Database)c.newInstance();
> logger.debug("Driver loaded.");
> // Register this database-driver to the concrete DB Manager of
> the XML:DB API
> DatabaseManager.registerDatabase(database);
> logger.debug("DB registered.");
> rootCollection = "xmldb:xindice-embed://"+
> ((host != null)?host:"localhost")+":"+
> ((port != null)?port:"4080")+"/"+
4080 port was used for CORBA in 1.0; it won't be used with 1.1, unless
you deploy xindice in tomcat and configure tomcat to listen on 4080.
> ((db != null)?db:"db")+"/MonA";
> logger.debug("rootCollection="+rootCollection);
>
> Collection col = DatabaseManager.getCollection(rootCollection);
>
> Does anybody know, how to fix this exception? The last line creates
> the exception.
See answer above :)
> The collection exists. I created it via command line.
> And: where do I have to put which configuration file when I don't want
> the db in
> my working directory?
There are system properties controlling this:
xindice.configuration - specifies config.xml filename
xindice.db.home - used to resolve db home if path in config.xml is
relative.
Vadim