Re: Back from the dead

On Saturday 14 December 2002 08:28, Kimbro Staken wrote: > Hey folks, been a while. :-) I apologize for disappearing without a > trace. I basically got knocked off the face of the internet by a server > outage that took all my domains with it. Unfortunately, it took forever > to get things fixed. M

Apache CVS server down?

Any news on this?

Embed driver: getId returns null... bug?

It's far less fancy than discovering how Xindice works or integrating it into the latest container server but I've finally decided -instead of -1 everything- to help the users and write an "embed driver tutorial". And fix bugs along the way (it looks like we still have a few). With the followi

Re: Embed driver: getId returns null... bug?

On Wednesday 18 December 2002 13:12, Vladimir R. Bossicard wrote: > It's far less fancy than discovering how Xindice works or integrating it > into the latest container server but I've finally decided -instead of -1 > everything- to help the users and write an "embed driver tutorial". > And fix bu

Re: Embed driver: getId returns null... bug?

On Wednesday 18 December 2002 14:31, James Bates wrote: > On Wednesday 18 December 2002 13:12, Vladimir R. Bossicard wrote: > > It's far less fancy than discovering how Xindice works or integrating it > > into the latest container server but I've finally decided -instead of -1 > > everything- to he

cvs commit: xml-xindice/src/documentation/resources/images comment.png comment.xcf pi.png pi.xcf

jbates 2002/12/18 05:22:21 Modified:src/documentation/content/xdocs/dev guide-internals.xml Added: src/documentation/resources/images comment.png comment.xcf pi.png pi.xcf Log: Finished compressed DOM and started query chapter Revision Changes

Re: Apache CVS server down?

On Wednesday 18 December 2002 12:34, James Bates wrote: > Any news on this? back up again...

Re: Embed driver: getId returns null... bug?

"Returns the unique id for this Resource or null if the Resource is anonymous. The Resource will be anonymous if it is obtained as the result of a query." Thanks for the detailed explanation. But why did I think that it was our fault? :-) I must confess I find this pretty strange, but I guess t

encapsulating unchecked exceptions

While browsing the code (and trying to understand it) I've seen a lot of code like this one: public void methodname() throws XMLDBException { code_that_can_throw_exeception; } Should we encapsulate the call between a try/catch block, like this: public void methodname() throws XMLDBExcep

Re: encapsulating unchecked exceptions

Vladimir R. Bossicard wrote: While browsing the code (and trying to understand it) I've seen a lot of code like this one: public void methodname() throws XMLDBException { code_that_can_throw_exeception; } Should we encapsulate the call between a try/catch block, like this: public void m

cvs commit: xml-xindice/src/documentation/content/xdocs/dev guide-internals.xml

jbates 2002/12/18 06:15:41 Modified:src/documentation/content/xdocs/dev guide-internals.xml Log: Completed XUpdate chapter Revision ChangesPath 1.10 +83 -6 xml-xindice/src/documentation/content/xdocs/dev/guide-internals.xml Index: guide-internals.xml ===

Re: encapsulating unchecked exceptions

I've worked quite a bit with exceptions in cocoon, so here are my 2c of wisdom. Thanks for the tip. I think that we are not very consequent regarding how we handle exceptions. Some examples: protected void createDriver(String uri) throws XMLDBException { try { } catch (Exc

Re: encapsulating unchecked exceptions

Vladimir R. Bossicard wrote: I've worked quite a bit with exceptions in cocoon, so here are my 2c of wisdom. Thanks for the tip. (rehashind the mail) > Do you have a strategy to fix this situation or other words of wisdom? Below are some possible strategies. I think that we are not very c

Re: Embed driver: getId returns null... bug?

I reported this long ago, (as some others did too) on this list, but as you've figured out, the XML:DB spec mandated it. I would appreciate it GREATLY if you would be willing to handle this inconsistency with those folks. After all, a Resource, no matter which way you get it, is still a Resou

Re: encapsulating unchecked exceptions

Ok, my 2cents, Don't catch and re-throw unless you have something to add, like a contextual message, or a context change (as it climbs to the top of the stack) -Kevin Vladimir R. Bossicard wrote: While browsing the code (and trying to understand it) I've seen a lot of code like this one: pub

Re: Embed driver: getId returns null... bug?

The problem is that depending on the XPath, a query can return all or part of a document. Documents have a resource ID (the document ID) and as such can be retrieved (in their entirity) from the database using that ID. A part of a document has no ID. The part can only be retrieved using an XPath th

Re: Embed driver: getId returns null... bug?

I reported this long ago, (as some others did too) on this list, but as you've figured out, the XML:DB spec mandated it. I would appreciate it GREATLY if you would be willing to handle this inconsistency with those folks. Why try to solve a problem? Vladimir will take care of it sooner or later

Re: Embed driver: getId returns null... bug?

Agreed, but, since the ID is available at times, doesn't it make sense to populate it in that case? If I use the database, querying a list of resources with IDs (like getting a personList), it wouldn't be out of line to expect the Java API to behave as it would when you call Collection.getRes

Re: Embed driver: getId returns null... bug?

The problem is that depending on the XPath, a query can return all or part of a document. Documents have a resource ID (the document ID) and as such can be retrieved (in their entirity) from the database using that ID. A part of a document has no ID. The part can only be retrieved using an XPath th

Re: Embed driver: getId returns null... bug?

Thanks Vladimir, you're a great help. I didn't try to solve it because I found it long ago before I was a committer. Since I use framework code for everything, I have already worked around it in one place, and I've forgotten entirely about it. Sorry to inconvenience you. -Kevin Vladimir R. Boss

[GUMP] Build Failure - xml-xindice

This email is autogenerated from the output from: Buildfile: build.xml init: [mkdir] Created dir: /home/rubys/jakarta/xml-x

Re: Embed driver: getId returns null... bug?

I think your suggested requirement places too great a burden on the implementation. The implementation would need to determine for each query whether or not what it is returning indeed has an ID. Am I returning a complete document or a fragment? I believe that the design is correct as-is. Hopefully

Re: Embed driver: getId returns null... bug?

But does it make sense for every user to implement the workaround (as I see it), or for the implementation to do it once? I do see your point, I guess it's a toss up. -Kevin Terry Rosenbaum wrote: I think your suggested requirement places too great a burden on the implementation. The implementati

Re: Embed driver: getId returns null... bug?

Vladimir R. Bossicard wrote: Very good explanation. So now the next (and last) step will be to put this into the documentation. Terry, thanks for volunteering. :-) Done. Attached is the updated guide-developer.xml file containing a new section below the section entitled "Querying with XPath". C

Re: Embed driver: getId returns null... bug?

On Wednesday 18 December 2002 15:54, Terry Rosenbaum wrote: > The problem is that depending on the XPath, > a query can return all or part of a document. > Documents have a resource ID (the document ID) > and as such can be retrieved (in their entirity) > from the database using that ID. A part of

cvs commit: xml-xindice/src/documentation/content/xdocs guide-developer.xml

jbates 2002/12/18 08:09:11 Modified:src/documentation/content/xdocs guide-developer.xml Log: Documentation update for getId()/getDocumentid() situation Submitted by: Terry Rosenbaum <[EMAIL PROTECTED]> Reviewed by: James Bates <[EMAIL PROTECTED]> Revision ChangesPa

Re: Embed driver: getId returns null... bug?

On Wednesday 18 December 2002 17:11, Terry Rosenbaum wrote: > Vladimir R. Bossicard wrote: > > Very good explanation. So now the next (and last) step will be to put > > this into the documentation. > > > > Terry, thanks for volunteering. :-) > > Done. > > Attached is the updated guide-developer.xm

Re: Embed driver: getId returns null... bug?

This isn't a bug, it's how it was designed. getID returns the ID only on resources that are actually documents, getDocumentID always returns the id for the document that contains returned resource. Basically if a node (i.e. resource) is retrieved from deep within the document then getID wil

Re: Embed driver: getId returns null... bug?

One other point on this. Resources will always have getDocumentID set. So if you consistently want to retrieve the ID for any document then this is the way to do it. Just remember it's the id for the containing document, not the resource itself. A resource retrieved from a query simply does

Re: encapsulating unchecked exceptions

You have to in this case though, it's the contract on the XML:DB API interface that requires the XMLDBException and doing it any other way introduces an incompatibility between the network and embedded drivers. On Wednesday, December 18, 2002, at 07:43 AM, Kevin Ross wrote: Ok, my 2cents, Don't

Xindice and the future

Wow, welcome back Kimbro! On the note of moving forward, I like the idea of Kimbro concentrating on a 2.0 architecture, using the lessons learned with the current codebase (because he knows more than anyone the lessons learned). I'm sure some of us committers without core development knowledge (o

Status

I am going to be traveling over the holidays and may or may not have Internet access, so I thought I'd keep everyone informed on what I have been up to and what I plan on doing:   1.  Secure XML:DB driver (SSL) - I have the driver ready to go and will try to comit it to the scratchpad soon. 

Re: Back from the dead

It REALLY is nice to see you back Kimbro! I think between what you are working on and the internals guide that James has been working on (btw, nice job James!) we stand to gain a lot in terms of core development, speed, transaction capabilities, etc.. Kurt - Original Message - From: "Ki