From ronald at innovation.ch Fri Oct 10 21:45:25 2008 From: ronald at innovation.ch (Life is hard, and then you die) Date: Fri, 10 Oct 2008 21:45:25 -0700 Subject: [Mulgara-dev] [Mulgara-svn] r1300 - trunk/src/jar/tuples/java/org/mulgara/store/tuples In-Reply-To: <20081010211718.594DA693346@gandalf.topazproject.org> References: <20081010211718.594DA693346@gandalf.topazproject.org> Message-ID: <20081011044525.GC11960@innovation.ch> On Fri, Oct 10, 2008 at 02:17:18PM -0700, alexhall at mulgara.org wrote: > Author: alexhall > Date: 2008-10-10 14:17:17 -0700 (Fri, 10 Oct 2008) > New Revision: 1300 > > Modified: > trunk/src/jar/tuples/java/org/mulgara/store/tuples/LiteralTuples.java > Log: > Adding an option to LiteralTuples to throw an exception if the > tuples is closed more than once, which will match the behavior of > HybridTuples. This is something I've noticed elsewhere (e.g. the connection code) and have wondering about: why isn't close() just idempotent? I.e. why throw an exception rather than just returning on a subsequent close? It seems to me that this isn't really that much of an error and it makes things simpler if you don't have trace all code everywhere to make sure close is only called once. Cheers, Ronald From DMS at viewpointusa.com Thu Oct 16 05:52:41 2008 From: DMS at viewpointusa.com (David Smith) Date: Thu, 16 Oct 2008 08:52:41 -0400 Subject: [Mulgara-dev] perhaps before 2.06 released - QueryResponsePage.java Message-ID: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F41@ROCHESTER01.viewpoint.local> I'd appreciate someone looking at before 2.0.6 released The lastest webui (playing with the current trunk), doesn't associate the correct model with the cells in the results, it always tries to look through "sampledata" when you click through the links it needs to pick up the GRAPH_ARG in "\src\jar\web\java\org\mulgara\webquery" Index: QueryResponsePage.java =================================================================== --- QueryResponsePage.java (revision 1326) +++ QueryResponsePage.java (working copy) @@ -108,7 +108,7 @@ this.unfinishedResults = (Map>)req.getSession().getAttribute(UNFINISHED _RESULTS); } - + /** * Send a result page to the client without any stats. This starts with a form template, and then * follows up with a single result. @@ -198,7 +198,7 @@ HtmlElement row = new TableRow(ROW_INDENT); row.add(new Span(CSS_LARGE, "Query Executed:")); row.add(new TableData(cmd.getText()).addAttr(Attr.VALIGN, "top").addAttr(Attr.WIDTH, "100%")); - + emitTopLevelElement(row); row = new TableRow(ROW_INDENT); @@ -312,7 +312,7 @@ */ private Anchor getElementQuery(Node n) throws IOException { try { - URI graphUri = new URI("rmi", tagMap.get(HOSTNAME_TAG), "/" + tagMap.get(SERVERNAME_TAG), "sampledata"); + URI graphUri = new URI( request.getParameter(GRAPH_ARG) ); QueryParams params = new QueryParams(); params.add(GRAPH_ARG, graphUri.toString()); String text; -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mulgara.org/pipermail/mulgara-dev/attachments/20081016/1cfa9a91/attachment.html From DMS at viewpointusa.com Thu Oct 16 05:56:27 2008 From: DMS at viewpointusa.com (David Smith) Date: Thu, 16 Oct 2008 08:56:27 -0400 Subject: [Mulgara-dev] perhaps before 2.0.6 released -- OrderedByRowComparator Message-ID: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F43@ROCHESTER01.viewpoint.local> I'd appreciate someone looking at before 2.0.6 released (I posted this back on Aug 1, 2008) OrderedByRowComparator doesn't correctly handle negative numbers... Thanks Dave Smith Viewpoint Data Management, LLC ============= Index: OrderByRowComparator.java =================================================================== --- OrderByRowComparator.java (revision 1118) +++ OrderByRowComparator.java (working copy) @@ -345,43 +345,37 @@ Node rdfNode = value; if (rdfNode instanceof Literal) { + String text = ((Literal) rdfNode).getLexicalForm(); - // Check if the string is a number. - int len = text.length(); - boolean isNumber = true; - boolean hasDecimalPoint = false; + if( text.length() > 0 ) + { + char ch= text.charAt(0); - if (logger.isDebugEnabled()) { + // if it smells like a numeric (and not a DateTime) + // + if( ((ch >= '0' && ch <= '9') || ch == '.' || ch == '+' || ch == '-' ) && !(text.indexOf('T') >= 0) ) + { + Float f= Float.NaN; + boolean isNumber= false; + try + { + f= new Float(text); + isNumber= true; + } + catch( NumberFormatException ex ) + { + } - logger.debug("Checking if " + text + " is a number"); - } + if( isNumber ) + { + return f; + } + } + } - // Check if the string is empty - isNumber = len > 0; - - for (int i = 0; i < len; ++i) { - char ch = text.charAt(i); - if (ch == '.') { - if (hasDecimalPoint) { - // A number can't have two decimal points. - isNumber = false; - break; - } - - hasDecimalPoint = true; - } else if ( (ch < '0') || (ch > '9')) { - // A char which is not a digit. - isNumber = false; - break; - } - } - - if (isNumber) { - return new Float(text); - } - return text; + } else if (rdfNode instanceof URIReference) { return ((URIReference) rdfNode).getURI().toString(); } else if (rdfNode instanceof BlankNode) { ============= create ; create ; delete select $s $o from where $s $o from ; insert '9000.0'^^ '-80.0'^^ '-8.8887'^^ '-8.00'^^ '6000'^^ '444'^^ '40.0'^^ '4.0'^^ '-11.0'^^ '-11.1'^^ '1'^^ '-1'^^ '11'^^ into ; select $s $o from where $s $o ; select $s $o from where $s $o order by $o asc ; select $s $o from where $s $o order by $o desc ; select $s $o from where $s $o and $o '-1'^^ in ; select $s $o from where $s $o and $o '7000'^^ in ; ============= From gearon at ieee.org Thu Oct 16 07:13:19 2008 From: gearon at ieee.org (Paul Gearon) Date: Thu, 16 Oct 2008 09:13:19 -0500 Subject: [Mulgara-dev] perhaps before 2.0.6 released -- OrderedByRowComparator In-Reply-To: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F43@ROCHESTER01.viewpoint.local> References: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F43@ROCHESTER01.viewpoint.local> Message-ID: Hi David, Sorry I never got to this before now. You caught me in the process of putting 2.0.6 out. This isn't too big a patch, so I think I can delay by the 30 minutes needed to get it in. However, I think I need to check it more carefully, as I don't think it's thorough enough. (The current code iterates over the entire string, but your test is partial) I've already added the other patch in. Since I was familiar with the web servlet (having ported it recently) I looked to see where this URL came from, and decided to re-use the tag map.... only to discover that you'd already worked this out. Oops. :-) Paul On Thu, Oct 16, 2008 at 7:56 AM, David Smith wrote: > I'd appreciate someone looking at before 2.0.6 released > > (I posted this back on Aug 1, 2008) > > OrderedByRowComparator doesn't correctly handle negative numbers... > > > Thanks > > Dave Smith > Viewpoint Data Management, LLC > > > > > ============= > Index: OrderByRowComparator.java > =================================================================== > --- OrderByRowComparator.java (revision 1118) > +++ OrderByRowComparator.java (working copy) > @@ -345,43 +345,37 @@ > Node rdfNode = value; > > if (rdfNode instanceof Literal) { > + > String text = ((Literal) rdfNode).getLexicalForm(); > > - // Check if the string is a number. > - int len = text.length(); > - boolean isNumber = true; > - boolean hasDecimalPoint = false; > + if( text.length() > 0 ) > + { > + char ch= text.charAt(0); > > - if (logger.isDebugEnabled()) { > + // if it smells like a numeric (and not a DateTime) > + // > + if( ((ch >= '0' && ch <= '9') || ch == '.' || ch == '+' || ch == > '-' ) && !(text.indexOf('T') >= 0) ) > + { > + Float f= Float.NaN; > + boolean isNumber= false; > + try > + { > + f= new Float(text); > + isNumber= true; > + } > + catch( NumberFormatException ex ) > + { > + } > > - logger.debug("Checking if " + text + " is a number"); > - } > + if( isNumber ) > + { > + return f; > + } > + } > + } > > - // Check if the string is empty > - isNumber = len > 0; > - > - for (int i = 0; i < len; ++i) { > - char ch = text.charAt(i); > - if (ch == '.') { > - if (hasDecimalPoint) { > - // A number can't have two decimal points. > - isNumber = false; > - break; > - } > - > - hasDecimalPoint = true; > - } else if ( (ch < '0') || (ch > '9')) { > - // A char which is not a digit. > - isNumber = false; > - break; > - } > - } > - > - if (isNumber) { > - return new Float(text); > - } > - > return text; > + > } else if (rdfNode instanceof URIReference) { > return ((URIReference) rdfNode).getURI().toString(); > } else if (rdfNode instanceof BlankNode) { > > > ============= > > create ; > create > ; > > delete > select $s $o > from > where > $s $o > from > > ; > > insert > > '9000.0'^^ > > '-80.0'^^ > > '-8.8887'^^ > > '-8.00'^^ > > '6000'^^ > > '444'^^ > > '40.0'^^ > > '4.0'^^ > > '-11.0'^^ > > '-11.1'^^ > > '1'^^ > > '-1'^^ > > '11'^^ > > > into ; > > select $s $o > from > where > $s $o > > ; > > > select $s $o > from > where > $s $o > > order by $o asc > > ; > > select $s $o > from > where > $s $o > > order by $o desc > > ; > > > select $s $o > from > where > $s $o and > $o > '-1'^^ in > > > ; > > select $s $o > from > where > $s $o and > $o > '7000'^^ in > > > ; > > ============= > _______________________________________________ > Mulgara-dev mailing list > Mulgara-dev at mulgara.org > http://mulgara.org/mailman/listinfo/mulgara-dev > From gearon at ieee.org Thu Oct 16 07:26:59 2008 From: gearon at ieee.org (Paul Gearon) Date: Thu, 16 Oct 2008 09:26:59 -0500 Subject: [Mulgara-dev] perhaps before 2.0.6 released -- OrderedByRowComparator In-Reply-To: References: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F43@ROCHESTER01.viewpoint.local> Message-ID: Just looked more carefully at the patch, and I see now that it you used the Float constructor to do the real test which is fine. Sorry for doubting. :-) Testing now. Paul On Thu, Oct 16, 2008 at 9:13 AM, Paul Gearon wrote: > Hi David, > > Sorry I never got to this before now. > > You caught me in the process of putting 2.0.6 out. This isn't too big > a patch, so I think I can delay by the 30 minutes needed to get it in. > However, I think I need to check it more carefully, as I don't think > it's thorough enough. (The current code iterates over the entire > string, but your test is partial) > > I've already added the other patch in. Since I was familiar with the > web servlet (having ported it recently) I looked to see where this URL > came from, and decided to re-use the tag map.... only to discover that > you'd already worked this out. Oops. :-) > > Paul > > On Thu, Oct 16, 2008 at 7:56 AM, David Smith wrote: >> I'd appreciate someone looking at before 2.0.6 released >> >> (I posted this back on Aug 1, 2008) >> >> OrderedByRowComparator doesn't correctly handle negative numbers... >> >> >> Thanks >> >> Dave Smith >> Viewpoint Data Management, LLC >> >> >> >> >> ============= >> Index: OrderByRowComparator.java >> =================================================================== >> --- OrderByRowComparator.java (revision 1118) >> +++ OrderByRowComparator.java (working copy) >> @@ -345,43 +345,37 @@ >> Node rdfNode = value; >> >> if (rdfNode instanceof Literal) { >> + >> String text = ((Literal) rdfNode).getLexicalForm(); >> >> - // Check if the string is a number. >> - int len = text.length(); >> - boolean isNumber = true; >> - boolean hasDecimalPoint = false; >> + if( text.length() > 0 ) >> + { >> + char ch= text.charAt(0); >> >> - if (logger.isDebugEnabled()) { >> + // if it smells like a numeric (and not a DateTime) >> + // >> + if( ((ch >= '0' && ch <= '9') || ch == '.' || ch == '+' || ch == >> '-' ) && !(text.indexOf('T') >= 0) ) >> + { >> + Float f= Float.NaN; >> + boolean isNumber= false; >> + try >> + { >> + f= new Float(text); >> + isNumber= true; >> + } >> + catch( NumberFormatException ex ) >> + { >> + } >> >> - logger.debug("Checking if " + text + " is a number"); >> - } >> + if( isNumber ) >> + { >> + return f; >> + } >> + } >> + } >> >> - // Check if the string is empty >> - isNumber = len > 0; >> - >> - for (int i = 0; i < len; ++i) { >> - char ch = text.charAt(i); >> - if (ch == '.') { >> - if (hasDecimalPoint) { >> - // A number can't have two decimal points. >> - isNumber = false; >> - break; >> - } >> - >> - hasDecimalPoint = true; >> - } else if ( (ch < '0') || (ch > '9')) { >> - // A char which is not a digit. >> - isNumber = false; >> - break; >> - } >> - } >> - >> - if (isNumber) { >> - return new Float(text); >> - } >> - >> return text; >> + >> } else if (rdfNode instanceof URIReference) { >> return ((URIReference) rdfNode).getURI().toString(); >> } else if (rdfNode instanceof BlankNode) { >> >> >> ============= >> >> create ; >> create >> ; >> >> delete >> select $s $o >> from >> where >> $s $o >> from >> >> ; >> >> insert >> >> '9000.0'^^ >> >> '-80.0'^^ >> >> '-8.8887'^^ >> >> '-8.00'^^ >> >> '6000'^^ >> >> '444'^^ >> >> '40.0'^^ >> >> '4.0'^^ >> >> '-11.0'^^ >> >> '-11.1'^^ >> >> '1'^^ >> >> '-1'^^ >> >> '11'^^ >> >> >> into ; >> >> select $s $o >> from >> where >> $s $o >> >> ; >> >> >> select $s $o >> from >> where >> $s $o >> >> order by $o asc >> >> ; >> >> select $s $o >> from >> where >> $s $o >> >> order by $o desc >> >> ; >> >> >> select $s $o >> from >> where >> $s $o and >> $o >> '-1'^^ in >> >> >> ; >> >> select $s $o >> from >> where >> $s $o and >> $o >> '7000'^^ in >> >> >> ; >> >> ============= >> _______________________________________________ >> Mulgara-dev mailing list >> Mulgara-dev at mulgara.org >> http://mulgara.org/mailman/listinfo/mulgara-dev >> > From DMS at viewpointusa.com Thu Oct 16 07:28:57 2008 From: DMS at viewpointusa.com (David Smith) Date: Thu, 16 Oct 2008 10:28:57 -0400 Subject: [Mulgara-dev] perhaps before 2.0.6 released --OrderedByRowComparator In-Reply-To: References: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F43@ROCHESTER01.viewpoint.local> Message-ID: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F63@ROCHESTER01.viewpoint.local> S'all good... Thanks for looking into it! Never really sure how much it costs to just let the try-catch handle it... I wanted to see if it was at least close to a number. DaveS -----Original Message----- From: mulgara-dev-bounces at mulgara.org [mailto:mulgara-dev-bounces at mulgara.org] On Behalf Of Paul Gearon Sent: Thursday, October 16, 2008 10:27 AM To: Mulgara Developers Subject: Re: [Mulgara-dev] perhaps before 2.0.6 released --OrderedByRowComparator Just looked more carefully at the patch, and I see now that it you used the Float constructor to do the real test which is fine. Sorry for doubting. :-) Testing now. Paul On Thu, Oct 16, 2008 at 9:13 AM, Paul Gearon wrote: > Hi David, > > Sorry I never got to this before now. > > You caught me in the process of putting 2.0.6 out. This isn't too big > a patch, so I think I can delay by the 30 minutes needed to get it in. > However, I think I need to check it more carefully, as I don't think > it's thorough enough. (The current code iterates over the entire > string, but your test is partial) > > I've already added the other patch in. Since I was familiar with the > web servlet (having ported it recently) I looked to see where this URL > came from, and decided to re-use the tag map.... only to discover that > you'd already worked this out. Oops. :-) > > Paul > > On Thu, Oct 16, 2008 at 7:56 AM, David Smith wrote: >> I'd appreciate someone looking at before 2.0.6 released >> >> (I posted this back on Aug 1, 2008) >> >> OrderedByRowComparator doesn't correctly handle negative numbers... >> >> >> Thanks >> >> Dave Smith >> Viewpoint Data Management, LLC >> >> >> >> >> ============= >> Index: OrderByRowComparator.java >> =================================================================== >> --- OrderByRowComparator.java (revision 1118) >> +++ OrderByRowComparator.java (working copy) >> @@ -345,43 +345,37 @@ >> Node rdfNode = value; >> >> if (rdfNode instanceof Literal) { >> + >> String text = ((Literal) rdfNode).getLexicalForm(); >> >> - // Check if the string is a number. >> - int len = text.length(); >> - boolean isNumber = true; >> - boolean hasDecimalPoint = false; >> + if( text.length() > 0 ) >> + { >> + char ch= text.charAt(0); >> >> - if (logger.isDebugEnabled()) { >> + // if it smells like a numeric (and not a DateTime) >> + // >> + if( ((ch >= '0' && ch <= '9') || ch == '.' || ch == '+' || ch == >> '-' ) && !(text.indexOf('T') >= 0) ) >> + { >> + Float f= Float.NaN; >> + boolean isNumber= false; >> + try >> + { >> + f= new Float(text); >> + isNumber= true; >> + } >> + catch( NumberFormatException ex ) >> + { >> + } >> >> - logger.debug("Checking if " + text + " is a number"); >> - } >> + if( isNumber ) >> + { >> + return f; >> + } >> + } >> + } >> >> - // Check if the string is empty >> - isNumber = len > 0; >> - >> - for (int i = 0; i < len; ++i) { >> - char ch = text.charAt(i); >> - if (ch == '.') { >> - if (hasDecimalPoint) { >> - // A number can't have two decimal points. >> - isNumber = false; >> - break; >> - } >> - >> - hasDecimalPoint = true; >> - } else if ( (ch < '0') || (ch > '9')) { >> - // A char which is not a digit. >> - isNumber = false; >> - break; >> - } >> - } >> - >> - if (isNumber) { >> - return new Float(text); >> - } >> - >> return text; >> + >> } else if (rdfNode instanceof URIReference) { >> return ((URIReference) rdfNode).getURI().toString(); >> } else if (rdfNode instanceof BlankNode) { >> >> >> ============= >> >> create ; >> create >> ; >> >> delete >> select $s $o >> from >> where >> $s $o >> from >> >> ; >> >> insert >> >> '9000.0'^^ >> >> '-80.0'^^ >> >> '-8.8887'^^ >> >> '-8.00'^^ >> >> '6000'^^ >> >> '444'^^ >> >> '40.0'^^ >> >> '4.0'^^ >> >> '-11.0'^^ >> >> '-11.1'^^ >> >> '1'^^ >> >> '-1'^^ >> >> '11'^^ >> >> >> into ; >> >> select $s $o >> from >> where >> $s $o >> >> ; >> >> >> select $s $o >> from >> where >> $s $o >> >> order by $o asc >> >> ; >> >> select $s $o >> from >> where >> $s $o >> >> order by $o desc >> >> ; >> >> >> select $s $o >> from >> where >> $s $o and >> $o >> '-1'^^ in >> >> >> ; >> >> select $s $o >> from >> where >> $s $o and >> $o >> '7000'^^ in >> >> >> ; >> >> ============= >> _______________________________________________ >> Mulgara-dev mailing list >> Mulgara-dev at mulgara.org >> http://mulgara.org/mailman/listinfo/mulgara-dev >> > _______________________________________________ Mulgara-dev mailing list Mulgara-dev at mulgara.org http://mulgara.org/mailman/listinfo/mulgara-dev From gearon at ieee.org Thu Oct 16 10:04:51 2008 From: gearon at ieee.org (Paul Gearon) Date: Thu, 16 Oct 2008 12:04:51 -0500 Subject: [Mulgara-dev] perhaps before 2.0.6 released --OrderedByRowComparator In-Reply-To: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F63@ROCHESTER01.viewpoint.local> References: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F43@ROCHESTER01.viewpoint.local> <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F63@ROCHESTER01.viewpoint.local> Message-ID: On Thu, Oct 16, 2008 at 9:28 AM, David Smith wrote: > S'all good... > > Thanks for looking into it! > > Never really sure how much it costs to just let the try-catch handle > it... > I wanted to see if it was at least close to a number. Which is pretty much what the previous version tried to do. I wouldn't worry about the cost of the try/catch. This only shows up if you have a LOT of data to work with. However, if that's the case, then the ORDER BY will need to put results on disk in order to sort them, and the cost of disk access will be much larger than the cost of setting up the exception frame. Regards, Paul From gearon at ieee.org Thu Oct 16 10:24:19 2008 From: gearon at ieee.org (Paul Gearon) Date: Thu, 16 Oct 2008 12:24:19 -0500 Subject: [Mulgara-dev] perhaps before 2.0.6 released -- OrderedByRowComparator In-Reply-To: References: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C3F43@ROCHESTER01.viewpoint.local> Message-ID: On Thu, Oct 16, 2008 at 9:26 AM, Paul Gearon wrote: > Just looked more carefully at the patch, and I see now that it you > used the Float constructor to do the real test which is fine. Sorry > for doubting. :-) > > Testing now. Hmmm, it looks like it needs another tweak. Float accepts values like "2d" as valid numbers. Paul From ronald at innovation.ch Thu Oct 16 14:04:47 2008 From: ronald at innovation.ch (Life is hard, and then you die) Date: Thu, 16 Oct 2008 14:04:47 -0700 Subject: [Mulgara-dev] [Mulgara-svn] r1335 - in trunk/src/jar: resolver-filesystem/java/org/mulgara/resolver/filesystem resolver-lucene/java/org/mulgara/resolver/lucene resolver-nodetype/java/org/mulgara/resolver/nodetype resolver-prefix/java/org/mulgara/resolver/prefix resolver-relational/java/org/mulgara/resolver/relational resolver-view/java/org/mulgara/resolver/view resolver-xsd/java/org/mulgara/resolver/xsd In-Reply-To: <20081016195010.20FAC69333D@gandalf.topazproject.org> References: <20081016195010.20FAC69333D@gandalf.topazproject.org> Message-ID: <20081016210447.GA568@innovation.ch> On Thu, Oct 16, 2008 at 12:50:10PM -0700, pag at mulgara.org wrote: > Author: pag > Date: 2008-10-16 12:50:09 -0700 (Thu, 16 Oct 2008) > New Revision: 1335 > > Modified: > trunk/src/jar/resolver-filesystem/java/org/mulgara/resolver/filesystem/FileSystemResolver.java > trunk/src/jar/resolver-lucene/java/org/mulgara/resolver/lucene/FullTextStringIndex.java > trunk/src/jar/resolver-lucene/java/org/mulgara/resolver/lucene/LuceneResolver.java > trunk/src/jar/resolver-nodetype/java/org/mulgara/resolver/nodetype/NodeTypeResolver.java > trunk/src/jar/resolver-prefix/java/org/mulgara/resolver/prefix/PrefixResolver.java > trunk/src/jar/resolver-relational/java/org/mulgara/resolver/relational/RelationalResolver.java > trunk/src/jar/resolver-view/java/org/mulgara/resolver/view/ViewResolver.java > trunk/src/jar/resolver-xsd/java/org/mulgara/resolver/xsd/XSDResolver.java > Log: > Changed messages of ignoring results to debug level [snip] > if (!(modelElem instanceof LocalNode)) { > - log.warn("Ignoring solutions for " + constraint); > + if (log.isDebugEnabled()) log.debug("Ignoring solutions for " + constraint); > return new EmptyResolution(constraint, false); Is this really ignorable? This seems like a significant error. Cheers, Ronald From alexhall at revelytix.com Thu Oct 16 14:19:28 2008 From: alexhall at revelytix.com (Alex Hall) Date: Thu, 16 Oct 2008 17:19:28 -0400 Subject: [Mulgara-dev] [Mulgara-svn] r1335 - in trunk/src/jar: resolver-filesystem/java/org/mulgara/resolver/filesystem resolver-lucene/java/org/mulgara/resolver/lucene resolver-nodetype/java/org/mulgara/resolver/nodetype resolver-prefix/java/org/mulgara/resolver/prefix resolver-relational/java/org/mulgara/resolver/relational resolver-view/java/org/mulgara/resolver/view resolver-xsd/java/org/mulgara/resolver/xsd In-Reply-To: <20081016210447.GA568@innovation.ch> References: <20081016195010.20FAC69333D@gandalf.topazproject.org> <20081016210447.GA568@innovation.ch> Message-ID: <48F7AFE0.5050905@revelytix.com> Life is hard, and then you die wrote: > On Thu, Oct 16, 2008 at 12:50:10PM -0700, pag at mulgara.org wrote: > >> Author: pag >> Date: 2008-10-16 12:50:09 -0700 (Thu, 16 Oct 2008) >> New Revision: 1335 >> >> Modified: >> trunk/src/jar/resolver-filesystem/java/org/mulgara/resolver/filesystem/FileSystemResolver.java >> trunk/src/jar/resolver-lucene/java/org/mulgara/resolver/lucene/FullTextStringIndex.java >> trunk/src/jar/resolver-lucene/java/org/mulgara/resolver/lucene/LuceneResolver.java >> trunk/src/jar/resolver-nodetype/java/org/mulgara/resolver/nodetype/NodeTypeResolver.java >> trunk/src/jar/resolver-prefix/java/org/mulgara/resolver/prefix/PrefixResolver.java >> trunk/src/jar/resolver-relational/java/org/mulgara/resolver/relational/RelationalResolver.java >> trunk/src/jar/resolver-view/java/org/mulgara/resolver/view/ViewResolver.java >> trunk/src/jar/resolver-xsd/java/org/mulgara/resolver/xsd/XSDResolver.java >> Log: >> Changed messages of ignoring results to debug level >> > [snip] > >> if (!(modelElem instanceof LocalNode)) { >> - log.warn("Ignoring solutions for " + constraint); >> + if (log.isDebugEnabled()) log.debug("Ignoring solutions for " + constraint); >> return new EmptyResolution(constraint, false); >> > > Is this really ignorable? This seems like a significant error. > Not necessarily. This would occur if the query contains a constraint with a variable model name, i.e. "select $s $p $o from where $s $p $o in $m". In this case the constraint is resolved against all internal resolvers, which maybe could resolve constraints with variable model names, but most choose not to. Regards, Alex From gearon at ieee.org Thu Oct 16 15:25:45 2008 From: gearon at ieee.org (Paul Gearon) Date: Thu, 16 Oct 2008 17:25:45 -0500 Subject: [Mulgara-dev] [Mulgara-svn] r1335 - in trunk/src/jar: resolver-filesystem/java/org/mulgara/resolver/filesystem resolver-lucene/java/org/mulgara/resolver/lucene resolver-nodetype/java/org/mulgara/resolver/nodetype resolver-prefix/java/org/mulgara/ Message-ID: On Thu, Oct 16, 2008 at 4:19 PM, Alex Hall wrote: > Life is hard, and then you die wrote: >> Is this really ignorable? This seems like a significant error. >> > Not necessarily. This would occur if the query contains a constraint > with a variable model name, i.e. "select $s $p $o from where $s > $p $o in $m". In this case the constraint is resolved against all > internal resolvers, which maybe could resolve constraints with variable > model names, but most choose not to. Alex is right on this point. The other thing is that Sesame gets several MILLION of these warnings in their benchmark tests, and in each case the resolvers in question are correctly ignoring the constraint. In fact, the only time you might want to know that a constraint has been ignored by a resolver is if you are writing or modifying resolver code. I don't think users will need to see it. If they ever did, then it would be such a specialized case that enabling debug logging would be an appropriate requirement anyway. Paul From DMS at viewpointusa.com Sat Oct 25 20:26:03 2008 From: DMS at viewpointusa.com (David Smith) Date: Sat, 25 Oct 2008 23:26:03 -0400 Subject: [Mulgara-dev] webui NextPage Message-ID: <690E83C1D15F5B4D84ACDAC9D0C1FD87014C4471@ROCHESTER01.viewpoint.local> The next page link on the webui does not honor the "current" Graph... (very similar to the link fix) Dave Smith Proposed patch Index: QueryResponsePage.java =================================================================== --- QueryResponsePage.java (revision 1362) +++ QueryResponsePage.java (working copy) @@ -357,8 +357,11 @@ */ private TableRow createNextLinkRow(Answer result, int width) throws IOException { try { - QueryParams param = new QueryParams(RESULT_ORD_ARG, getNrToBeResumed(result)); - Anchor a = new Anchor(new URI(EXECUTE_LINK + "?" + param), "Next page >"); + // borrow this info out of the tag map + URI graphUri = new URI(tagMap.get(GRAPH_TAG)); + QueryParams params = new QueryParams(RESULT_ORD_ARG, getNrToBeResumed(result)); + params.add(GRAPH_ARG, graphUri.toString()); + Anchor a = new Anchor(new URI(EXECUTE_LINK + "?" + params), "Next page >"); a.addAttr(Attr.TITLE, "Forward to next page of results"); return new TableRow(new TableData(a).addAttr(Attr.COLSPAN, width)); } catch (URISyntaxException e) { From alexhall at revelytix.com Tue Oct 28 08:43:15 2008 From: alexhall at revelytix.com (Alex Hall) Date: Tue, 28 Oct 2008 11:43:15 -0400 Subject: [Mulgara-dev] RDF/XML parse errors Message-ID: <49073313.8070603@revelytix.com> All, I think that the RDF/XML content handler might be a little trigger-happy when it comes to throwing exceptions reported by the ARP parser. I'm trying to use Mulgara to parse the RDF/XML output of a third-party web service. It turns out that the RDF/XML is not entirely valid, yet Jena is able to import the document and ignore the invalid portions, while Mulgara rejects the document altogether. Both tools use the ARP parser and see the same parse error, but only Mulgara stops processing when it encounters the error. Taking a closer look, the Parser class in the RDF/XML content handler implements the SAX ErrorHandler interface, which ARP uses to report problems back to the calling application. The ErrorHandler interface specifies three different levels of problem: warning, error, and fatal error. The particular problem that I'm seeing falls into the "error" category. However, the SAX documentation defines "error" as a recoverable condition. As used by ARP, it appears to mean that the invalid portion of an RDF/XML document will be ignored, and parsing of the valid portion will continue. Of course, the ideal solution is to work with only valid RDF/XML documents. But when we're working with generated documents from external sources, that isn't always possible, and it would be nice to get the valid content out of such documents on a best-effort basis. I see two approaches to mitigate this situation: 1. Change the content handler to log reported errors and continue parsing, to match the default Jena behavior. Only fatal errors will cause an exception to be thrown by the content handler. 2. Make the error handling behavior configurable -- perhaps add an option for "strict" or "lax" parsing mode. The quick-and-dirty way would be to use a Java system property, but I don't like that because those options tend to get lost over time. It would be nice to extend the MulgaraConfig framework to allow for passing configuration options into system components, but I'm not sure I'm willing to bite off that task for such a minor change :-) I prefer option 1, but I'm open to option 2. Thoughts or suggestions? Regards, Alex From gearon at ieee.org Tue Oct 28 09:54:26 2008 From: gearon at ieee.org (Paul Gearon) Date: Tue, 28 Oct 2008 11:54:26 -0500 Subject: [Mulgara-dev] RDF/XML parse errors In-Reply-To: <49073313.8070603@revelytix.com> References: <49073313.8070603@revelytix.com> Message-ID: On Tue, Oct 28, 2008 at 10:43 AM, Alex Hall wrote: > All, > > I think that the RDF/XML content handler might be a little trigger-happy > when it comes to throwing exceptions reported by the ARP parser. I'm > trying to use Mulgara to parse the RDF/XML output of a third-party web > service. It turns out that the RDF/XML is not entirely valid, yet Jena > is able to import the document and ignore the invalid portions, while > Mulgara rejects the document altogether. Both tools use the ARP parser > and see the same parse error, but only Mulgara stops processing when it > encounters the error. > > Taking a closer look, the Parser class in the RDF/XML content handler > implements the SAX ErrorHandler interface, which ARP uses to report > problems back to the calling application. The ErrorHandler interface > specifies three different levels of problem: warning, error, and fatal > error. The particular problem that I'm seeing falls into the "error" > category. However, the SAX documentation defines "error" as a > recoverable condition. As used by ARP, it appears to mean that the > invalid portion of an RDF/XML document will be ignored, and parsing of > the valid portion will continue. Ah. I didn't go into this, but I knew I had to. This is the reason I upgraded the ARP parser a few weeks ago.... I wanted any problems to be ours. It is frustrating to find that an error is coming from a library that you are using, and even more so when you discover that there is a more recent version of the library in question. I also wanted to be able to debug my way into the library and our version of ARP was hard to find the source code for. The thing that was causing me a problem was when the parser encountered an EOF immediately after the final , instead of a newline. Reading from a file is OK, but it fails on an InputStream. If the error handling is the mechanism where this can be fixed then I'll be very grateful to you for doing my work for me. :-) > Of course, the ideal solution is to work with only valid RDF/XML > documents. But when we're working with generated documents from > external sources, that isn't always possible, and it would be nice to > get the valid content out of such documents on a best-effort basis. I > see two approaches to mitigate this situation: > > 1. Change the content handler to log reported errors and continue > parsing, to match the default Jena behavior. Only fatal errors will > cause an exception to be thrown by the content handler. > > 2. Make the error handling behavior configurable -- perhaps add an > option for "strict" or "lax" parsing mode. The quick-and-dirty way > would be to use a Java system property, but I don't like that because > those options tend to get lost over time. It would be nice to extend > the MulgaraConfig framework to allow for passing configuration options > into system components, but I'm not sure I'm willing to bite off that > task for such a minor change :-) > > I prefer option 1, but I'm open to option 2. Thoughts or suggestions? Option 1. Option 2 doesn't make too much sense in an Open World (though it would be more relevant if this was for a RDBMS). I figure that if Option 2 is ever needed, then the developer who needs it will just have to check their data sources themselves. Besides, they can always build their own RDF/XML content handler. :-) Paul From ronald at innovation.ch Tue Oct 28 15:55:58 2008 From: ronald at innovation.ch (Life is hard, and then you die) Date: Tue, 28 Oct 2008 15:55:58 -0700 Subject: [Mulgara-dev] RDF/XML parse errors In-Reply-To: References: <49073313.8070603@revelytix.com> Message-ID: <20081028225558.GA26430@innovation.ch> On Tue, Oct 28, 2008 at 11:54:26AM -0500, Paul Gearon wrote: > On Tue, Oct 28, 2008 at 10:43 AM, Alex Hall wrote: > > > > I think that the RDF/XML content handler might be a little trigger-happy > > when it comes to throwing exceptions reported by the ARP parser. I'm > > trying to use Mulgara to parse the RDF/XML output of a third-party web > > service. It turns out that the RDF/XML is not entirely valid, yet Jena > > is able to import the document and ignore the invalid portions, while > > Mulgara rejects the document altogether. Both tools use the ARP parser > > and see the same parse error, but only Mulgara stops processing when it > > encounters the error. [snip] > > 1. Change the content handler to log reported errors and continue > > parsing, to match the default Jena behavior. Only fatal errors will > > cause an exception to be thrown by the content handler. > > > > 2. Make the error handling behavior configurable -- perhaps add an > > option for "strict" or "lax" parsing mode. The quick-and-dirty way > > would be to use a Java system property, but I don't like that because > > those options tend to get lost over time. It would be nice to extend > > the MulgaraConfig framework to allow for passing configuration options > > into system components, but I'm not sure I'm willing to bite off that > > task for such a minor change :-) > > > > I prefer option 1, but I'm open to option 2. Thoughts or suggestions? I'd prefer option 2. The problem with the logs is that from an application perspective they're not visible, so it looks like everything is fine and you don't notice any problems until somebody goes and analyzes the logs. However, I do appreciate your point about how to configure this - adding an attribute to the MulgaraConfig is easy enough, but that object is available to anything but the SessionFactoryFactory's. > Option 1. Option 2 doesn't make too much sense in an Open World > (though it would be more relevant if this was for a RDBMS). I figure > that if Option 2 is ever needed, then the developer who needs it will > just have to check their data sources themselves. Besides, they can > always build their own RDF/XML content handler. :-) I don't think the open-world assumption is a reason for saying I'll accept any garbage in my db. For applications that do want that, I would indeed say they can build their own garbage handler :-) Cheers, Ronald From alexhall at revelytix.com Wed Oct 29 15:38:30 2008 From: alexhall at revelytix.com (Alex Hall) Date: Wed, 29 Oct 2008 18:38:30 -0400 Subject: [Mulgara-dev] RDF/XML parse errors In-Reply-To: <20081028225558.GA26430@innovation.ch> References: <49073313.8070603@revelytix.com> <20081028225558.GA26430@innovation.ch> Message-ID: <4908E5E6.1010708@revelytix.com> Life is hard, and then you die wrote: [snip] >>> 1. Change the content handler to log reported errors and continue >>> parsing, to match the default Jena behavior. Only fatal errors will >>> cause an exception to be thrown by the content handler. >>> >>> 2. Make the error handling behavior configurable -- perhaps add an >>> option for "strict" or "lax" parsing mode. The quick-and-dirty way >>> would be to use a Java system property, but I don't like that because >>> those options tend to get lost over time. It would be nice to extend >>> the MulgaraConfig framework to allow for passing configuration options >>> into system components, but I'm not sure I'm willing to bite off that >>> task for such a minor change :-) >>> >>> I prefer option 1, but I'm open to option 2. Thoughts or suggestions? > > I'd prefer option 2. The problem with the logs is that from an > application perspective they're not visible, so it looks like > everything is fine and you don't notice any problems until somebody > goes and analyzes the logs. > > However, I do appreciate your point about how to configure this - > adding an attribute to the MulgaraConfig is easy enough, but that > object is available to anything but the SessionFactoryFactory's. Do you mean unavailable? Yes, this is a shame, especially since ARP (like the rest of Jena) is extremely configurable with respect to how it handles parse errors. There are three built-in levels of error handling: default, strict, and lax (we use lax right now). Of these, "strict" is said to implement the W3C recommendations, although it neglects to mention where said recommendations are located. You can go even further and customize the error level for all the individual error codes. It would be nice to expose some of these configuration options to the end user. If there were a way of configuring the content handler using MulgaraConfig then I would be much more open to option 2. But there isn't, and I don't have the time to write one, which is why I'm leaning towards option 1. >> Option 1. Option 2 doesn't make too much sense in an Open World >> (though it would be more relevant if this was for a RDBMS). I figure >> that if Option 2 is ever needed, then the developer who needs it will >> just have to check their data sources themselves. Besides, they can >> always build their own RDF/XML content handler. :-) > > I don't think the open-world assumption is a reason for saying I'll > accept any garbage in my db. For applications that do want that, I > would indeed say they can build their own garbage handler :-) Let me point out that not throwing exceptions for recoverable errors will not cause your db to be filled with "any old garbage". A recoverable error means that the associated resource (i.e. XML element) that caused the error will not generate any statements. Basically, the parser unwinds the stack back up the document tree until a non-error state is reached and continues parsing as normal with the next child element. The specific example that I'm working with is importing an RDF/XML document exported from the OpenCalais entity extractor. OpenCalais, still being in beta, has a relatively minor bug where it omits the rdf:parseType="XMLLiteral" attribute on a property element where it is stuffing external metadata. Such an oversight is not sufficient reason for me to want to reject the entire document; I just want the 99% of the file that is valid. Saying that I'm not going to accept any input that is not 100% valid RDF/XML assumes that I have complete control over the content of that input, which in this case I clearly do not. And if you do have tighter control over the source of your input, I don't see any harm in relaxing your parsing rules anyways. Regards, Alex From alexhall at revelytix.com Wed Oct 29 16:08:25 2008 From: alexhall at revelytix.com (Alex Hall) Date: Wed, 29 Oct 2008 19:08:25 -0400 Subject: [Mulgara-dev] W3C RDF Test Cases in Mulgara Message-ID: <4908ECE9.9020605@revelytix.com> While investigating the RDF/XML parsing issues, I came across some copies of RDF test cases from the W3C, located in a couple of places: data/RDF-Test-Cases-2001-09-12.zip and jxdata/w3c. These test cases are intended to verify compliance with the RDF/XML specification, but we don't appear to be using them that way. If that's the case, then their presence is confusing. I've already found a couple of obsolete test cases that are still included in the Mulgara project (the test cases reference the deprecated rdf:aboutEach and rdf:bagID constructs). The ARP content handler throws errors for these test cases, yet they are used as part of the backup/restore JXUnit test. Could somebody please clarify the use of these test cases in Mulgara? Seeing how we're using Jena's parser, it seems kind of silly to keep around a bunch of old parser test cases. Regards, Alex From gearon at ieee.org Thu Oct 30 06:43:17 2008 From: gearon at ieee.org (Paul Gearon) Date: Thu, 30 Oct 2008 08:43:17 -0500 Subject: [Mulgara-dev] RDF/XML parse errors In-Reply-To: <4908E5E6.1010708@revelytix.com> References: <49073313.8070603@revelytix.com> <20081028225558.GA26430@innovation.ch> <4908E5E6.1010708@revelytix.com> Message-ID: On Wed, Oct 29, 2008 at 5:38 PM, Alex Hall wrote: > If there were a way of configuring the content handler using MulgaraConfig then > I would be much more open to option 2. But there isn't, and I don't have the > time to write one, which is why I'm leaning towards option 1. I would say option 1, and put the configuration for fine-control up on Trac as a ticket. >> I don't think the open-world assumption is a reason for saying I'll >> accept any garbage in my db. For applications that do want that, I >> would indeed say they can build their own garbage handler :-) > > Let me point out that not throwing exceptions for recoverable errors will not > cause your db to be filled with "any old garbage". A recoverable error means > that the associated resource (i.e. XML element) that caused the error will not > generate any statements. Basically, the parser unwinds the stack back up the > document tree until a non-error state is reached and continues parsing as normal > with the next child element. This was why I considered it acceptable to accept the remainder of the document. Paul From gearon at ieee.org Thu Oct 30 06:48:21 2008 From: gearon at ieee.org (Paul Gearon) Date: Thu, 30 Oct 2008 08:48:21 -0500 Subject: [Mulgara-dev] W3C RDF Test Cases in Mulgara In-Reply-To: <4908ECE9.9020605@revelytix.com> References: <4908ECE9.9020605@revelytix.com> Message-ID: On Wed, Oct 29, 2008 at 6:08 PM, Alex Hall wrote: > While investigating the RDF/XML parsing issues, I came across some copies of RDF > test cases from the W3C, located in a couple of places: > data/RDF-Test-Cases-2001-09-12.zip and jxdata/w3c. These test cases are > intended to verify compliance with the RDF/XML specification, but we don't > appear to be using them that way. If that's the case, then their presence is > confusing. I've already found a couple of obsolete test cases that are still > included in the Mulgara project (the test cases reference the deprecated > rdf:aboutEach and rdf:bagID constructs). The ARP content handler throws errors > for these test cases, yet they are used as part of the backup/restore JXUnit test. > > Could somebody please clarify the use of these test cases in Mulgara? Seeing > how we're using Jena's parser, it seems kind of silly to keep around a bunch of > old parser test cases. Apparently these were put in a LONG time ago, probably when the RDF/XML content handler was first created. I think we need to check that we can load RDF/XML data through ARP, but there is not need to test compliance carefully, as we trust ARP to do that for us. If they're not being used, then we can drop them (particularly if they're obsolete). If they ARE being used, then we should either update the data and test or drop the test - whichever seems more appropriate. Paul From ronald at innovation.ch Thu Oct 30 16:34:51 2008 From: ronald at innovation.ch (Life is hard, and then you die) Date: Thu, 30 Oct 2008 16:34:51 -0700 Subject: [Mulgara-dev] RDF/XML parse errors In-Reply-To: <4908E5E6.1010708@revelytix.com> References: <49073313.8070603@revelytix.com> <20081028225558.GA26430@innovation.ch> <4908E5E6.1010708@revelytix.com> Message-ID: <20081030233451.GC11055@innovation.ch> On Wed, Oct 29, 2008 at 06:38:30PM -0400, Alex Hall wrote: > Life is hard, and then you die wrote: > [snip] > >>> 1. Change the content handler to log reported errors and continue > >>> parsing, to match the default Jena behavior. Only fatal errors will > >>> cause an exception to be thrown by the content handler. > >>> > >>> 2. Make the error handling behavior configurable -- perhaps add an > >>> option for "strict" or "lax" parsing mode. The quick-and-dirty way > >>> would be to use a Java system property, but I don't like that because > >>> those options tend to get lost over time. It would be nice to extend > >>> the MulgaraConfig framework to allow for passing configuration options > >>> into system components, but I'm not sure I'm willing to bite off that > >>> task for such a minor change :-) > >>> > >>> I prefer option 1, but I'm open to option 2. Thoughts or suggestions? > > > > I'd prefer option 2. The problem with the logs is that from an > > application perspective they're not visible, so it looks like > > everything is fine and you don't notice any problems until somebody > > goes and analyzes the logs. > > > > However, I do appreciate your point about how to configure this - > > adding an attribute to the MulgaraConfig is easy enough, but that > > object is available to anything but the SessionFactoryFactory's. > > Do you mean unavailable? Yes, sorry. [snip] > If there were a way of configuring the content handler using > MulgaraConfig then I would be much more open to option 2. But there > isn't, and I don't have the time to write one, which is why I'm > leaning towards option 1. I understand - we're all lazy. :-) [snip] > > I don't think the open-world assumption is a reason for saying I'll > > accept any garbage in my db. For applications that do want that, I > > would indeed say they can build their own garbage handler :-) > > Let me point out that not throwing exceptions for recoverable errors > will not cause your db to be filled with "any old garbage". A > recoverable error means that the associated resource (i.e. XML > element) that caused the error will not generate any statements. > Basically, the parser unwinds the stack back up the document tree > until a non-error state is reached and continues parsing as normal > with the next child element. [snip] Ok. Then I stand corrected: this is compatible with the open-world assumption. Cheers, Ronald From gearon at ieee.org Thu Oct 30 19:51:08 2008 From: gearon at ieee.org (Paul Gearon) Date: Thu, 30 Oct 2008 21:51:08 -0500 Subject: [Mulgara-dev] [Mulgara-svn] r1370 - trunk In-Reply-To: <20081031022831.3EE0D69333D@gandalf.topazproject.org> References: <20081031022831.3EE0D69333D@gandalf.topazproject.org> Message-ID: Hi Eddie, Which code is using client-jrdf? Also, you're still using the JRDF interface, right? Paul On Thu, Oct 30, 2008 at 9:28 PM, wrote: > Author: eddie > Date: 2008-10-30 19:28:30 -0700 (Thu, 30 Oct 2008) > New Revision: 1370 > > Modified: > trunk/build.xml > Log: > added client-jrdf back to core-dist (the dependency was still there, but the actual jar inclusion was dropped in r1232) > > Modified: trunk/build.xml > =================================================================== > --- trunk/build.xml 2008-10-30 14:46:17 UTC (rev 1369) > +++ trunk/build.xml 2008-10-31 02:28:30 UTC (rev 1370) > @@ -1930,6 +1930,7 @@ > > > > + > > > > > _______________________________________________ > Mulgara-svn mailing list > Mulgara-svn at mulgara.org > http://mulgara.org/mailman/listinfo/mulgara-svn > From eddie at fedora-commons.org Thu Oct 30 22:25:11 2008 From: eddie at fedora-commons.org (Edwin Shin) Date: Fri, 31 Oct 2008 13:25:11 +0800 Subject: [Mulgara-dev] [Mulgara-svn] r1370 - trunk In-Reply-To: References: <20081031022831.3EE0D69333D@gandalf.topazproject.org> Message-ID: <490A96B7.301@fedora-commons.org> Yes, we're still using the JRDF interface in Fedora (via Trippi). I just found out about the packaging change b/c a user reported a ClassNotFoundException while trying to use Fedora with a remote instance of Mulgara. By dependency I meant that the core-dist target still declared client-jrdf in depends. Did you pull this out deliberately? I didn't see any comment to that effect so I assumed it was just a cut&paste error, especially since the depends was still there and 2.0.0 - 2.0.4 went out with client-jrdf included in mulgara-core. Actually I'd still rather see org.jrdf get pulled out of mulgara-core (or re-homed to org.mulgara), but that's a topic for another time. Maybe over a pint next week ;) On 10/31/2008 10:51 AM, Paul Gearon is rumored to have said: > Hi Eddie, > > Which code is using client-jrdf? > > Also, you're still using the JRDF interface, right? > > Paul > > On Thu, Oct 30, 2008 at 9:28 PM, wrote: >> Author: eddie >> Date: 2008-10-30 19:28:30 -0700 (Thu, 30 Oct 2008) >> New Revision: 1370 >> >> Modified: >> trunk/build.xml >> Log: >> added client-jrdf back to core-dist (the dependency was still there, but the actual jar inclusion was dropped in r1232) >> >> Modified: trunk/build.xml >> =================================================================== >> --- trunk/build.xml 2008-10-30 14:46:17 UTC (rev 1369) >> +++ trunk/build.xml 2008-10-31 02:28:30 UTC (rev 1370) >> @@ -1930,6 +1930,7 @@ >> >> >> >> + >> >> >> >> >> _______________________________________________ >> Mulgara-svn mailing list >> Mulgara-svn at mulgara.org >> http://mulgara.org/mailman/listinfo/mulgara-svn >> > _______________________________________________ > Mulgara-dev mailing list > Mulgara-dev at mulgara.org > http://mulgara.org/mailman/listinfo/mulgara-dev From gearon at ieee.org Fri Oct 31 07:01:46 2008 From: gearon at ieee.org (Paul Gearon) Date: Fri, 31 Oct 2008 09:01:46 -0500 Subject: [Mulgara-dev] [Mulgara-svn] r1370 - trunk In-Reply-To: <490A96B7.301@fedora-commons.org> References: <20081031022831.3EE0D69333D@gandalf.topazproject.org> <490A96B7.301@fedora-commons.org> Message-ID: On Fri, Oct 31, 2008 at 12:25 AM, Edwin Shin wrote: > Yes, we're still using the JRDF interface in Fedora (via Trippi). I just > found out about the packaging change b/c a user reported a > ClassNotFoundException while trying to use Fedora with a remote instance > of Mulgara. > > By dependency I meant that the core-dist target still declared > client-jrdf in depends. Did you pull this out deliberately? I didn't see > any comment to that effect so I assumed it was just a cut&paste error, > especially since the depends was still there and 2.0.0 - 2.0.4 went out > with client-jrdf included in mulgara-core. Sort of. I was trying to remove as much as I could. Since I don't use JRDF then I didn't see a problem when this got removed as well. > Actually I'd still rather see org.jrdf get pulled out of mulgara-core > (or re-homed to org.mulgara), but that's a topic for another time. Maybe > over a pint next week ;) I desperately want this as well, but I was scared about the third party code I'd be breaking (like yours). Paul