<?xml version="1.0" encoding="UTF-8" ?>




<!--  RSS generated by JIRA 108 at Sun May 19 05:55:56 CEST 2013 -->
<rss version="0.92">





<channel>
    <title>openRDF.org Issue Tracker</title>
    <link>http://www.openrdf.org/issues</link>
    <description>This file is an XML representation of some issues</description>
    <language>en</language>

    
<item>

    







<title>[SES-1109] SPARQL 1.1 HAVING when used with aggrateions fails with &quot;Node is not a child node&quot;</title>
<link>http://www.openrdf.org/issues/browse/SES-1109</link>

    
        <description>The following query results in an error&lt;br/&gt;
&lt;br/&gt;
SELECT ?p (COUNT(?o) as ?objects) {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[] ?p ?o .&lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
GROUP BY ?p&lt;br/&gt;
HAVING(?objects &amp;gt; 1)&lt;br/&gt;
ORDER BY DESC(?objects)&lt;br/&gt;
&lt;br/&gt;
Query error: Unexpected failure getting metadata for query &apos;QueryDescription &apos; SELECT ?p (COUNT(?o) as ?objects) { [] ?p ?o . } GROUP BY ?p HAVING(?objects &amp;gt; 0) ORDER BY DESC(?objects) &apos; (SPARQL, QueryModifier (100, 0, {}), impacts)&apos; caused by : Node is not a child node: Group (p) StatementPattern Var (name=-anon-1, anonymous) Var (name=p) Var (name=o) GroupElem Count Var (name=o)</description>
    
    
        <environment></environment>
    
        <key id="14140">SES-1109</key>
        <summary>SPARQL 1.1 HAVING when used with aggrateions fails with &quot;Node is not a child node&quot;</summary>
        <type id="1">Bug</type>
    
        <priority id="4">Minor</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="5">Cannot Reproduce</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="carlbray">Carl Bray</reporter>
        
    

        
        <created>Mon, 1 Oct 2012 14:34:37 +0200 (CEST)</created>
    <updated>Thu, 4 Oct 2012 22:20:26 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Query Engine</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="dwvisser" created="Mon, 1 Oct 2012 18:02:42 +0200 (CEST)" level="">I failed to reproduce this issue on Sesame 2.6.9 in a repository loaded with the triples file available at &lt;a href=&quot;http://www.rdfdata.org/dat/rdfdata.rdf&quot;&gt;http://www.rdfdata.org/dat/rdfdata.rdf&lt;/a&gt;. This was the query in Workbench 2.6.9: &lt;br/&gt;
&lt;br/&gt;
PREFIX :&amp;lt;&lt;a href=&quot;http://purl.org/dc/elements/1.1/&quot;&gt;http://purl.org/dc/elements/1.1/&lt;/a&gt;&amp;gt;&lt;br/&gt;
PREFIX rdf:&amp;lt;&lt;a href=&quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#&quot;&gt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&lt;/a&gt;&amp;gt;&lt;br/&gt;
PREFIX rd:&amp;lt;&lt;a href=&quot;http://www.rdfdata.org/ns/&quot;&gt;http://www.rdfdata.org/ns/&lt;/a&gt;&amp;gt;&lt;br/&gt;
SELECT ?p (COUNT(?o) as ?objects) {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;[] ?p ?o .&lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
GROUP BY ?p&lt;br/&gt;
HAVING(?objects &amp;gt; 1)&lt;br/&gt;
ORDER BY DESC(?objects)&lt;br/&gt;
&lt;br/&gt;
I have attached the XML results response.</comment>
            
            <comment author="carlbray" created="Mon, 1 Oct 2012 18:21:23 +0200 (CEST)" level="">Thanks for taking a look.&lt;br/&gt;
I&apos;ll see if I can get you more info...</comment>
            
            <comment author="jeen" created="Mon, 1 Oct 2012 21:53:02 +0200 (CEST)" level="">The error is not one that is produced by a standard Sesame repository. Can you describe the exact environment you are testing this in? &lt;br/&gt;
</comment>
            
            <comment author="carlbray" created="Thu, 4 Oct 2012 12:23:09 +0200 (CEST)" level="">We tracked this down to a bug in our code. &lt;br/&gt;
&lt;br/&gt;
We were getting the getTupleExpr from ParsedQuery and not cloning it.&lt;br/&gt;
&lt;br/&gt;
Sorry for the false alarm.</comment>
            
            <comment author="jeen" created="Thu, 4 Oct 2012 22:20:26 +0200 (CEST)" level="">No problem, thanks for letting us know!</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1108] GROUP BY aggregates incorrectly with nothing to aggregate</title>
<link>http://www.openrdf.org/issues/browse/SES-1108</link>

    
        <description>With an empty (in-memory) repository, the following query:&lt;br/&gt;
&lt;br/&gt;
SELECT ?type (COUNT(DISTINCT ?instance) AS ?count) WHERE {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;?instance &amp;lt;&lt;a href=&quot;http://example.com#predicate&quot;&gt;http://example.com#predicate&lt;/a&gt;&amp;gt; ?type .&lt;br/&gt;
}&lt;br/&gt;
GROUP BY ?type &lt;br/&gt;
&lt;br/&gt;
Returns:&lt;br/&gt;
&lt;br/&gt;
Type Count&lt;br/&gt;
(null) 0&lt;br/&gt;
&lt;br/&gt;
I believe it should not return anything at all.&lt;br/&gt;
&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="14130">SES-1108</key>
        <summary>GROUP BY aggregates incorrectly with nothing to aggregate</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="2">Won&apos;t Fix</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="bazbishop">Barry Bishop</reporter>
        
    

        
        <created>Mon, 24 Sep 2012 10:44:47 +0200 (CEST)</created>
    <updated>Wed, 26 Sep 2012 02:32:44 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Query Engine</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="rvesse" created="Mon, 24 Sep 2012 18:30:16 +0200 (CEST)" level="">I disagree, I believe this is in fact the correct behavior&lt;br/&gt;
&lt;br/&gt;
See &lt;a href=&quot;http://answers.semanticweb.com/questions/17410/semantics-of-sparql-aggregates&quot;&gt;http://answers.semanticweb.com/questions/17410/semantics-of-sparql-aggregates&lt;/a&gt; for a recent discussion on this with input from WG member Andy Seaborne which explains why you still get a result</comment>
            
            <comment author="jeen" created="Mon, 24 Sep 2012 22:38:14 +0200 (CEST)" level="">Thanks for that link Rob. Barry, are you happy that that answers the question? &lt;br/&gt;
</comment>
            
            <comment author="jeen" created="Mon, 24 Sep 2012 22:41:15 +0200 (CEST)" level="">Note, by the way, that in the example given in Rob&apos;s link, the result is a row with two unbound values, rather than a value for the aggregate. This is because the aggregate used there is MAX, which is undefined on an empty list and therefore returns an error (which becomes unbound). In contrast, COUNT on an empty list is defined, so it returns 0.</comment>
            
            <comment author="bazbishop" created="Tue, 25 Sep 2012 00:18:37 +0200 (CEST)" level="">Well, having read up on it then I think this does explain the behaviour. I believe it is correct, just rather strange for someone who is familiar with SQL.</comment>
            
            <comment author="jeen" created="Wed, 26 Sep 2012 02:32:44 +0200 (CEST)" level="">I agree it&apos;s a bit strange, but it is consistent with the spec, so marking this as a won&apos;t fix.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1107] Paging through query results causes URL to keep growing</title>
<link>http://www.openrdf.org/issues/browse/SES-1107</link>

    
        <description>The JavaScript responding to form actions in the query results page always causes the URL to grow in length. For larger query texts, his has the potential to make the URL grow too long to handle. &lt;br/&gt;
&lt;br/&gt;
The code is always appending new copies of URL query parameters. (This presently works because the same code uses only the last value in the URL.) It should test for the presence of the changing parameter in the URL and replace it.</description>
    
    
        <environment></environment>
    
        <key id="14122">SES-1107</key>
        <summary>Paging through query results causes URL to keep growing</summary>
        <type id="1">Bug</type>
    
        <priority id="4">Minor</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="dwvisser">Dale W. Visser</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Fri, 21 Sep 2012 19:48:51 +0200 (CEST)</created>
    <updated>Thu, 4 Oct 2012 01:49:52 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Web interface</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="dwvisser" created="Thu, 4 Oct 2012 01:49:52 +0200 (CEST)" level="">Same check-in that fixed &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-376&quot; title=&quot;Explore option in web client should use LIMIT (with next and previous buttons)&quot;&gt;&lt;strike&gt;SES-376&lt;/strike&gt;&lt;/a&gt; fixed this as well: revision 11976</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1105] Query Page javascript broken on Internet Explorer 9</title>
<link>http://www.openrdf.org/issues/browse/SES-1105</link>

    
        <description>There is an issue where Internet Explorer 9 HTML-escapes characters in the JavaScript included in the XSL template files. Specifically a test using the &apos;&amp;gt;&apos; operator gets broken by a replacement with &amp;amp;gt;. This particular instance of the issue doesn&apos;t cause a problem. However, in recent checkins for &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-376&quot; title=&quot;Explore option in web client should use LIMIT (with next and previous buttons)&quot;&gt;&lt;strike&gt;SES-376&lt;/strike&gt;&lt;/a&gt;, I have introduced more JavaScript into the tuple results XSL template with &apos;&amp;lt;&apos; and &apos;&amp;gt;&apos; comparisons. This difference in IE 9 breaks proper display of results.&lt;br/&gt;
&lt;br/&gt;
I have already coded and tested a fix which simply moves the JavaScript from these files into separate *.js files in the scripts folder.</description>
    
    
        <environment>Internet Explorer 9 using Workbench</environment>
    
        <key id="14120">SES-1105</key>
        <summary>Query Page javascript broken on Internet Explorer 9</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="dwvisser">Dale W. Visser</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Fri, 21 Sep 2012 19:27:36 +0200 (CEST)</created>
    <updated>Thu, 27 Sep 2012 22:29:37 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Web interface</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Wed, 26 Sep 2012 02:22:12 +0200 (CEST)" level="">supplied patch by dale committed in revision 11971</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1102] Mishandling of brackets in Property Paths</title>
<link>http://www.openrdf.org/issues/browse/SES-1102</link>

    
        <description>The following programm executes two sparql expressions which to me should both retrieve the same subject and object. But they do not. &lt;br/&gt;
&lt;br/&gt;
	public static void main(String[] args) throws Exception {&lt;br/&gt;
		Repository repo = new SailRepository(new MemoryStore());&lt;br/&gt;
		repo.initialize();&lt;br/&gt;
&lt;br/&gt;
		ValueFactory f = repo.getValueFactory();&lt;br/&gt;
&lt;br/&gt;
		URI a = f.createURI(&amp;quot;urn:a&amp;quot;);&lt;br/&gt;
		URI b = f.createURI(&amp;quot;urn:b&amp;quot;);&lt;br/&gt;
		URI c = f.createURI(&amp;quot;urn:c&amp;quot;);&lt;br/&gt;
&lt;br/&gt;
		RepositoryConnection con = repo.getConnection();&lt;br/&gt;
		con.add(a, f.createURI(&amp;quot;property:x&amp;quot;), b);&lt;br/&gt;
		con.add(b, f.createURI(&amp;quot;property:y&amp;quot;), c);&lt;br/&gt;
&lt;br/&gt;
		//To me, these queries should result in the same output&lt;br/&gt;
		String[] queries = new String[2];&lt;br/&gt;
		queries[0] = &amp;quot;SELECT ?m ?n WHERE { ?m &amp;lt;property:x&amp;gt;/&amp;lt;property:y&amp;gt; ?n }&amp;quot;;&lt;br/&gt;
		queries[1] = &amp;quot;SELECT ?m ?n WHERE { ?m &amp;lt;property:x&amp;gt;/(&amp;lt;property:y&amp;gt;) ?n }&amp;quot;;&lt;br/&gt;
&lt;br/&gt;
		int i = 0;&lt;br/&gt;
		for (String q : queries) {&lt;br/&gt;
			TupleQuery query = con.prepareTupleQuery(QueryLanguage.SPARQL, q);&lt;br/&gt;
			TupleQueryResult result = query.evaluate();&lt;br/&gt;
&lt;br/&gt;
			String resultStr = &amp;quot;No Result&amp;quot;;&lt;br/&gt;
			while (result.hasNext()) {&lt;br/&gt;
				BindingSet bindingSet = result.next();&lt;br/&gt;
				Value m = bindingSet.getValue(&amp;quot;m&amp;quot;);&lt;br/&gt;
				Value n = bindingSet.getValue(&amp;quot;n&amp;quot;);&lt;br/&gt;
				resultStr = &amp;quot;&amp;quot; + m + &amp;quot; | &amp;quot; + n;&lt;br/&gt;
			}&lt;br/&gt;
			System.out.println(i + &amp;quot;: &amp;quot; + resultStr);&lt;br/&gt;
			i++;&lt;br/&gt;
		}&lt;br/&gt;
		con.close();&lt;br/&gt;
	}&lt;br/&gt;
&lt;br/&gt;
It results in the following output:&lt;br/&gt;
0: urn:a | urn:c&lt;br/&gt;
1: No Result&lt;br/&gt;
&lt;br/&gt;
I would expect it to result in the following output: &lt;br/&gt;
0: urn:a | urn:c&lt;br/&gt;
1: urn:a | urn:c&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="14091">SES-1102</key>
        <summary>Mishandling of brackets in Property Paths</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="rehei">Heiner Reinhardt</reporter>
        
    

        
        <created>Tue, 18 Sep 2012 21:32:37 +0200 (CEST)</created>
    <updated>Tue, 30 Oct 2012 23:48:02 +0100 (CET)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.10</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Tue, 30 Oct 2012 23:36:25 +0100 (CET)" level="">bug is in query parser. &lt;br/&gt;
&lt;br/&gt;
Query 1 produces:&lt;br/&gt;
&lt;br/&gt;
Projection&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;ProjectionElemList&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;ProjectionElem &amp;quot;m&amp;quot;&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;ProjectionElem &amp;quot;n&amp;quot;&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;Join&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;StatementPattern&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=m)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=-const-1, value=property:x, anonymous)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=-const-1-0, anonymous)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;StatementPattern&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=-const-1-0, anonymous)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=-const-2, value=property:y, anonymous)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=n)&lt;br/&gt;
&lt;br/&gt;
Query 2 produces:&lt;br/&gt;
&lt;br/&gt;
Projection&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;ProjectionElemList&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;ProjectionElem &amp;quot;m&amp;quot;&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;ProjectionElem &amp;quot;n&amp;quot;&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;Join&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;StatementPattern&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=m)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=-const-1, value=property:x, anonymous)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=-const-1-0, anonymous)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;StatementPattern&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=m) &lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=-const-2, value=property:y, anonymous)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;Var (name=n)&lt;br/&gt;
&lt;br/&gt;
The subject variable of the second statement pattern in q2 is incorrect.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1100] openrdf-sesame.war webapp resets http.proxyHost JVM-wide system property</title>
<link>http://www.openrdf.org/issues/browse/SES-1100</link>

    
        <description>Upon container start-up, the openrdf-sesame.war resets the http.proxyHost JVM-wide system property as well as the other proxy-related system properties.&lt;br/&gt;
&lt;br/&gt;
It should not do so or, at least, leave a way for the system (administrator) to manage the proxy settings directly (e.g. Mac OS X manages proxies at system level and taken into account by the JVM as &amp;quot;java.net.useSystemProxies&amp;quot; defaults to true on this platform).&lt;br/&gt;
For example, proxy-related system properties should not be modified when Sesame&apos;s configuration property &amp;quot;proxies.enabled&amp;quot; is set to false.&lt;br/&gt;
&lt;br/&gt;
Proposed patch: modify info.aduna.app.net.ProxySettings.setProxySystemProperty() as follows:&lt;br/&gt;
&lt;br/&gt;
	private void setProxySystemProperty(String key, String val) {&lt;br/&gt;
		if (getProxiesEnabled()) {&lt;br/&gt;
			setSystemProperty(key, val);&lt;br/&gt;
		}&lt;br/&gt;
		// No Sesame-specific proxy configuration =&amp;gt; leave system configuration unchanged.&lt;br/&gt;
		// else {&lt;br/&gt;
		// 	setSystemProperty(key, null);&lt;br/&gt;
		// }&lt;br/&gt;
	}&lt;br/&gt;
&lt;br/&gt;
Web applications should never alter the system-properties set at the command-line unless explicitely instructed to do so (which thus can not be the default behaviour).&lt;br/&gt;
&lt;br/&gt;
For the long term, if Sesame needs an specific proxy configuration that differs from the system default, it should create an application-wide java.net.Proxy object with this configuration and use it when establishing network connections.&lt;br/&gt;
&lt;br/&gt;
Note: this bug was created with priority Major as Sesame proxy configuration is not described anywhere (a web search on &amp;quot;proxies.enabled&amp;quot; brings back nothing), resulting in hours lost in useless debugging.&lt;br/&gt;
</description>
    
    
        <environment>Mac OS X 10.6 / Java 1.6.0_35</environment>
    
        <key id="14081">SES-1100</key>
        <summary>openrdf-sesame.war webapp resets http.proxyHost JVM-wide system property</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="lbihanic">Laurent Bihanic</reporter>
        
    

        
        <created>Tue, 18 Sep 2012 00:04:49 +0200 (CEST)</created>
    <updated>Wed, 31 Oct 2012 21:48:41 +0100 (CET)</updated>

    
        
        
            
            
                
                    <version>2.6.6</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.10</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Configuration</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Wed, 31 Oct 2012 21:48:41 +0100 (CET)" level="">fixed in 2.6 branch, revision 11998. &lt;br/&gt;
&lt;br/&gt;
Regarding better documentation, good point, will be taken into account into an upcoming major overhaul of site and documentation.</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10020">
            <name>Related</name>
                
                
                    <outwardlinks description="is related to">
                    
                        <issuelink>
                            <issuekey id="14050">SES-1093</issuekey>
                        </issuelink>
                    
                    </outwardlinks>
                
                
                
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1096] Position of BIND() affects query results</title>
<link>http://www.openrdf.org/issues/browse/SES-1096</link>

    
        <description>Being a declarative language, I would not expect the ordering of SPARQL clauses to affect the query results. However, BIND is a bit strange, so perhaps I have misunderstood. This might be the correct behaviour.&lt;br/&gt;
&lt;br/&gt;
Steps to reproduce:&lt;br/&gt;
&lt;br/&gt;
1. Create new in memory store (no inference)&lt;br/&gt;
2. Insert a simple class hierarchy of 3 classes:&lt;br/&gt;
&lt;br/&gt;
PREFIX rdfs:&amp;lt;&lt;a href=&quot;http://www.w3.org/2000/01/rdf-schema#&quot;&gt;http://www.w3.org/2000/01/rdf-schema#&lt;/a&gt;&amp;gt;&lt;br/&gt;
PREFIX my: &amp;lt;&lt;a href=&quot;http://ex#&quot;&gt;http://ex#&lt;/a&gt;&amp;gt;&lt;br/&gt;
INSERT DATA {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;my:Concept rdfs:subClassOf my:Super1 .&lt;br/&gt;
&amp;nbsp;&amp;nbsp;my:Super1 rdfs:subClassOf my:Super2 .&lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
3. Execute query:&lt;br/&gt;
&lt;br/&gt;
PREFIX rdfs:&amp;lt;&lt;a href=&quot;http://www.w3.org/2000/01/rdf-schema#&quot;&gt;http://www.w3.org/2000/01/rdf-schema#&lt;/a&gt;&amp;gt;&lt;br/&gt;
PREFIX my: &amp;lt;&lt;a href=&quot;http://ex#&quot;&gt;http://ex#&lt;/a&gt;&amp;gt;&lt;br/&gt;
SELECT ?super {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;BIND( my:Concept as ?concept )&lt;br/&gt;
&amp;nbsp;&amp;nbsp;?concept rdfs:subClassOf ?super .&lt;br/&gt;
&amp;nbsp;&amp;nbsp;OPTIONAL {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;?concept rdfs:subClassOf ?inbetweener .&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;?inbetweener rdfs:subClassOf ?super .&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;FILTER( ?inbetweener != ?concept &amp;amp;&amp;amp; ?inbetweener != ?super )&lt;br/&gt;
&amp;nbsp;&amp;nbsp;}&lt;br/&gt;
&amp;nbsp;&amp;nbsp;FILTER( ! BOUND(?inbetweener) &amp;amp;&amp;amp; ?super != ?concept)&lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
Gives expected result: super=&amp;lt;&lt;a href=&quot;http://ex#Super1&quot;&gt;http://ex#Super1&lt;/a&gt;&amp;gt;&lt;br/&gt;
&lt;br/&gt;
4. Execute the same query, but move the BIND clause from the top to the bottom:&lt;br/&gt;
&lt;br/&gt;
PREFIX rdfs:&amp;lt;&lt;a href=&quot;http://www.w3.org/2000/01/rdf-schema#&quot;&gt;http://www.w3.org/2000/01/rdf-schema#&lt;/a&gt;&amp;gt;&lt;br/&gt;
PREFIX my: &amp;lt;&lt;a href=&quot;http://ex#&quot;&gt;http://ex#&lt;/a&gt;&amp;gt;&lt;br/&gt;
SELECT ?super {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;?concept rdfs:subClassOf ?super .&lt;br/&gt;
&amp;nbsp;&amp;nbsp;OPTIONAL {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;?concept rdfs:subClassOf ?inbetweener .&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;?inbetweener rdfs:subClassOf ?super .&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;FILTER( ?inbetweener != ?concept &amp;amp;&amp;amp; ?inbetweener != ?super )&lt;br/&gt;
&amp;nbsp;&amp;nbsp;}&lt;br/&gt;
&amp;nbsp;&amp;nbsp;FILTER( ! BOUND(?inbetweener) &amp;amp;&amp;amp; ?super != ?concept)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;BIND( my:Concept as ?concept )&lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
Unexpected result: super=&amp;lt;&lt;a href=&quot;http://ex#Super1&amp;gt;,&quot;&gt;http://ex#Super1&amp;amp;gt;,&lt;/a&gt; super=&amp;lt;&lt;a href=&quot;http://ex#Super2&quot;&gt;http://ex#Super2&lt;/a&gt;&amp;gt;</description>
    
    
        <environment>Sesame 2.6.9 in-memory store (and other SAIL implementations)</environment>
    
        <key id="14070">SES-1096</key>
        <summary>Position of BIND() affects query results</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="2">Won&apos;t Fix</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="bazbishop">Barry Bishop</reporter>
        
    

        
        <created>Fri, 14 Sep 2012 08:16:48 +0200 (CEST)</created>
    <updated>Fri, 14 Sep 2012 23:58:59 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.10</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Query Engine</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="bazbishop" created="Fri, 14 Sep 2012 08:28:22 +0200 (CEST)" level="">It is as I feared, I believe I have misused BIND, since Working Draft 24 July 2012 says:&lt;br/&gt;
&lt;br/&gt;
&amp;quot;Use of BIND ends the preceding basic graph pattern and the variable introduced by the BIND clause must not have been used in the immediate preceding basic graph pattern or property path expression.&amp;quot;&lt;br/&gt;
&lt;br/&gt;
Please disregard this bug report.&lt;br/&gt;
&lt;br/&gt;
Although, can the parser me modified to check for this kind of improper use of a variable already used in the preceding graph pattern?</comment>
            
            <comment author="dwvisser" created="Fri, 14 Sep 2012 16:11:29 +0200 (CEST)" level="">You beat me by 30 about minutes to posting the same text from the standard. :-)&lt;br/&gt;
&lt;br/&gt;
I agree that there is a fix to be made here, namely that the parser declares the query invalid if the variable has already been used in the pattern before the BIND.</comment>
            
            <comment author="jeen" created="Fri, 14 Sep 2012 23:51:23 +0200 (CEST)" level="">I was going to comment that strictly speaking, the query is not invalid. However, looking at the text in the new working draft, it seems that it _is_ supposed to be considered invalid. AFAICT this is new. I will take a look at what we can do to fix this - either generate a warning or just flat-out throw an error.</comment>
            
            <comment author="jeen" created="Fri, 14 Sep 2012 23:58:58 +0200 (CEST)" level="">As discussed in comments: not a bug. Followup issue (&lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-1098&quot; title=&quot;Query parser should report error when BIND is used with a variable that appears in the preceeding BGP&quot;&gt;SES-1098&lt;/a&gt;) created for generating a parse error on invalid use of BIND.</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10030">
            <name>Followup</name>
                
                
                
                
                
                    <inwardlinks description="is followed up by">
                    
                        <issuelink>
                            <issuekey id="14072">SES-1098</issuekey>
                        </issuelink>
                    
                    </inwardlinks>
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1095] TimeLimitIteration can cause excessive memory use</title>
<link>http://www.openrdf.org/issues/browse/SES-1095</link>

    
        <description>TimeLimitIteration create instances of an anonymous class derived from TimerTask and adds them to a singleton instance of Timer.&lt;br/&gt;
&lt;br/&gt;
When an iteration is complete, it cancels each TimerTask object, however Timer does not purge cancelled TimerTasks from its queue - it waits until the appropriate time to execute them and then if they are cancelled just discards them. Flushing the Timer&apos;s queue at the moment when a TimerTask is cancelled is not very efficient.&lt;br/&gt;
&lt;br/&gt;
So a problem can arise when a large number of queries are executed and the Timer&apos;s queue grows, because each of the iteration objects can not be garbage collected while they are waiting to time-out (even they they are closed/finished).&lt;br/&gt;
&lt;br/&gt;
I suggest a solution where The TimerTask associated with each TimeLimitIteration sets its reference to the iteration object to null at the point where it is cancelled (closed).&lt;br/&gt;
&lt;br/&gt;
I will attach a suggested implementation of TimeLimitIteration to this issue.</description>
    
    
        <environment></environment>
    
        <key id="14060">SES-1095</key>
        <summary>TimeLimitIteration can cause excessive memory use</summary>
        <type id="4">Improvement</type>
    
        <priority id="2">Critical</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="bazbishop">Barry Bishop</reporter>
        
    

        
        <created>Thu, 13 Sep 2012 09:00:46 +0200 (CEST)</created>
    <updated>Wed, 31 Oct 2012 22:33:46 +0100 (CET)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.10</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Query Model</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="bazbishop" created="Thu, 13 Sep 2012 09:03:25 +0200 (CEST)" level="">A suggested alternative implementation of TimeLimitIteration that allows Iteration object to be garbage collected when they are closed, but have not timed-out.&lt;br/&gt;
&lt;br/&gt;
This implementation is not finished: The appropriate type arguments must be added to the generic inner class. It has also not been fully tested, so please consider it a &apos;suggestion&apos;.</comment>
            
            <comment author="jeen" created="Fri, 14 Sep 2012 07:45:22 +0200 (CEST)" level="">Good catch, this.&lt;br/&gt;
&lt;br/&gt;
I&apos;m thinking whether another alternative, perhaps slightly simpler to implement, is to use a WeakReference instead. </comment>
            
            <comment author="jeen" created="Fri, 14 Sep 2012 08:00:05 +0200 (CEST)" level="">Checked in a possible fix in the 2.6 branch, revision 11966. &lt;br/&gt;
&lt;br/&gt;
See &lt;a href=&quot;http://repo.aduna-software.org/websvn/diff.php?repname=aduna&amp;path=%2Forg.openrdf%2Fsesame%2Fbranches%2F2.6%2Fcore%2Fquery%2Fsrc%2Fmain%2Fjava%2Finfo%2Faduna%2Fiteration%2FTimeLimitIteration.java&amp;rev=0&amp;sc=1&quot;&gt;http://repo.aduna-software.org/websvn/diff.php?repname=aduna&amp;amp;path=%2Forg.openrdf%2Fsesame%2Fbranches%2F2.6%2Fcore%2Fquery%2Fsrc%2Fmain%2Fjava%2Finfo%2Faduna%2Fiteration%2FTimeLimitIteration.java&amp;amp;rev=0&amp;amp;sc=1&lt;/a&gt; &lt;br/&gt;
&lt;br/&gt;
The fix introduces a WeakReference to keep a handle on the TimerTask. This should allow the TimeLimitIteration object to be GC&apos;d when closed (even if the TimerTask is still referenced in the Timer). &lt;br/&gt;
&lt;br/&gt;
Thinking about it a bit more, this is probably not enough though. The core of the problem is that TimerTask is an inner class which has an (implicit) strong reference to its outer class, the TimeLimitIteration. Possibly the best way forward is to actually make TimerTask a separate class, so we have control over its reference to TimeLimitIteration.</comment>
            
            <comment author="jeen" created="Fri, 14 Sep 2012 08:12:21 +0200 (CEST)" level="">Implemented slight variation of suggested fix by Barry. See &lt;a href=&quot;http://repo.aduna-software.org/websvn/listing.php?repname=aduna&amp;path=%2Forg.openrdf%2Fsesame%2Fbranches%2F2.6%2Fcore%2Fquery%2Fsrc%2Fmain%2Fjava%2Finfo%2Faduna%2Fiteration%2F&amp;rev=11967&amp;sc=1&quot;&gt;http://repo.aduna-software.org/websvn/listing.php?repname=aduna&amp;amp;path=%2Forg.openrdf%2Fsesame%2Fbranches%2F2.6%2Fcore%2Fquery%2Fsrc%2Fmain%2Fjava%2Finfo%2Faduna%2Fiteration%2F&amp;amp;rev=11967&amp;amp;sc=1&lt;/a&gt;. &lt;br/&gt;
&lt;br/&gt;
Needs testing and feedback.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1091] Using setBinding on query variable in property path loses that binding from result set</title>
<link>http://www.openrdf.org/issues/browse/SES-1091</link>

    
        <description>Problem reported on mailinglist by Peter Ansell (see &lt;a href=&quot;http://sourceforge.net/mailarchive/message.php?msg_id=29766713&quot;&gt;http://sourceforge.net/mailarchive/message.php?msg_id=29766713&lt;/a&gt; ) &lt;br/&gt;
&lt;br/&gt;
Data set:&lt;br/&gt;
&lt;br/&gt;
@prefix rdfs: &amp;lt;&lt;a href=&quot;http://www.w3.org/2000/01/rdf-schema#&quot;&gt;http://www.w3.org/2000/01/rdf-schema#&lt;/a&gt;&amp;gt; .&lt;br/&gt;
@prefix rdf: &amp;lt;&lt;a href=&quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#&quot;&gt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&lt;/a&gt;&amp;gt; .&lt;br/&gt;
@prefix owl: &amp;lt;&lt;a href=&quot;http://www.w3.org/2002/07/owl#&quot;&gt;http://www.w3.org/2002/07/owl#&lt;/a&gt;&amp;gt; .&lt;br/&gt;
@prefix obo: &amp;lt;&lt;a href=&quot;http://purl.obolibrary.org/obo/&quot;&gt;http://purl.obolibrary.org/obo/&lt;/a&gt;&amp;gt; .&lt;br/&gt;
&lt;br/&gt;
obo:PO_0025131 rdfs:subClassOf owl:Thing .&lt;br/&gt;
obo:PO_0025131 rdf:type owl:Class .&lt;br/&gt;
obo:PO_0009011 rdf:type owl:Class .&lt;br/&gt;
obo:PO_0009011 rdfs:subClassOf obo:PO_0025131 .&lt;br/&gt;
obo:PO_0025117 rdf:type owl:Class .&lt;br/&gt;
obo:PO_0025117 rdfs:subClassOf obo:PO_0025131 .&lt;br/&gt;
obo:PO_0025161 rdf:type owl:Class .&lt;br/&gt;
obo:PO_0025161 rdfs:subClassOf obo:PO_0025131 .&lt;br/&gt;
&lt;br/&gt;
Query:&lt;br/&gt;
&lt;br/&gt;
SELECT ?parent ?child &lt;br/&gt;
WHERE { &lt;br/&gt;
&amp;nbsp;&amp;nbsp;?child a owl:Class . &lt;br/&gt;
&amp;nbsp;&amp;nbsp;?child rdfs:subClassOf+ ?parent . &lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
Executed without setting any bindings, result:&lt;br/&gt;
&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0025131;parent=http://www.w3.org/2002/07/owl#Thing&quot;&gt;http://purl.obolibrary.org/obo/PO_0025131;parent=http://www.w3.org/2002/07/owl#Thing&lt;/a&gt;]&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0009011;parent=http://purl.obolibrary.org/obo/PO_0025131&quot;&gt;http://purl.obolibrary.org/obo/PO_0009011;parent=http://purl.obolibrary.org/obo/PO_0025131&lt;/a&gt;]&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0009011;parent=http://www.w3.org/2002/07/owl#Thing&quot;&gt;http://purl.obolibrary.org/obo/PO_0009011;parent=http://www.w3.org/2002/07/owl#Thing&lt;/a&gt;]&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0025117;parent=http://purl.obolibrary.org/obo/PO_0025131&quot;&gt;http://purl.obolibrary.org/obo/PO_0025117;parent=http://purl.obolibrary.org/obo/PO_0025131&lt;/a&gt;]&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0025117;parent=http://www.w3.org/2002/07/owl#Thing&quot;&gt;http://purl.obolibrary.org/obo/PO_0025117;parent=http://www.w3.org/2002/07/owl#Thing&lt;/a&gt;]&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0025161;parent=http://purl.obolibrary.org/obo/PO_0025131&quot;&gt;http://purl.obolibrary.org/obo/PO_0025161;parent=http://purl.obolibrary.org/obo/PO_0025131&lt;/a&gt;]&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0025161;parent=http://www.w3.org/2002/07/owl#Thing&quot;&gt;http://purl.obolibrary.org/obo/PO_0025161;parent=http://www.w3.org/2002/07/owl#Thing&lt;/a&gt;]&lt;br/&gt;
&lt;br/&gt;
Executed with using setBinding on parent, to value owl:Thing, result:&lt;br/&gt;
&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0025131&quot;&gt;http://purl.obolibrary.org/obo/PO_0025131&lt;/a&gt;]&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0009011&quot;&gt;http://purl.obolibrary.org/obo/PO_0009011&lt;/a&gt;]&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0025117&quot;&gt;http://purl.obolibrary.org/obo/PO_0025117&lt;/a&gt;]&lt;br/&gt;
[child=&lt;a href=&quot;http://purl.obolibrary.org/obo/PO_0025161&quot;&gt;http://purl.obolibrary.org/obo/PO_0025161&lt;/a&gt;]&lt;br/&gt;
&lt;br/&gt;
While the result seems to be correct wrt to the &apos;child&apos; variable (these four results are the correct set of transitive subclasses for owl:Thing), for some reason the &apos;parent&apos; variable has been lost from the result.</description>
    
    
        <environment></environment>
    
        <key id="14042">SES-1091</key>
        <summary>Using setBinding on query variable in property path loses that binding from result set</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="pansell">Peter Ansell</reporter>
        
    

        
        <created>Wed, 5 Sep 2012 22:52:05 +0200 (CEST)</created>
    <updated>Thu, 6 Sep 2012 06:01:35 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.10</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Query Engine</component>
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Wed, 5 Sep 2012 22:55:05 +0200 (CEST)" level="">Having played around with it a bit, this seems to be a bug in the ArbitraryLengthPath evaluation. At least, the problem does not occur if I remove the &apos;+&apos; sign behind subclassof in the query. I&apos;ve also noticed that if I use a FILTER clause instead of a setBinding, the query seems to not return any results at all. I have a gut feeling that is caused by the same bug though.</comment>
            
            <comment author="jeen" created="Wed, 5 Sep 2012 23:25:14 +0200 (CEST)" level="">Cause is that PathIteration wrongly assumes that any fixed value does not need to be added to the result bindingset. Fix is a oneliner, need to integrate a couple of test cases though.</comment>
            
            <comment author="jeen" created="Wed, 5 Sep 2012 23:47:39 +0200 (CEST)" level="">fixed in 2.6 branch, revision 11946. </comment>
            
            <comment author="pansell" created="Thu, 6 Sep 2012 04:02:14 +0200 (CEST)" level="">A simpler query is still failing for me on the small test file:&lt;br/&gt;
&lt;br/&gt;
SELECT ?parent ?child&lt;br/&gt;
WHERE {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;?child rdfs:subClassOf+ ?parent .&lt;br/&gt;
} &lt;br/&gt;
&lt;br/&gt;
In addition, all of the other queries I am working with are still failing on larger files. After the bug with the query above on the small test file I can work on a slightly larger test case if necessary.&lt;br/&gt;
&lt;br/&gt;
For reference, the other two queries I am planning to use in my project are the following: &lt;br/&gt;
&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;SELECT DISTINCT ?parent (COUNT(DISTINCT ?child) AS ?childCount)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;WHERE { ?child a owl:Class . ?child rdfs:subClassOf+ ?parent . FILTER(isIRI(?child) &amp;amp;&amp;amp; isIRI(?parent)) }&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;GROUP BY ?parent&lt;br/&gt;
&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;SELECT DISTINCT ?parent ?child&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;WHERE { ?child a owl:Class . ?child rdfs:subClassOf+ ?parent . FILTER(isIRI(?child) &amp;amp;&amp;amp; isIRI(?parent)) }&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;ORDER BY DESC(?child) LIMIT 10000 OFFSET 0&lt;br/&gt;
&lt;br/&gt;
Both of these queries are passing on the small test file for me, so they may not be of use for debugging until a larger test case is developed.&lt;br/&gt;
</comment>
            
            <comment author="jeen" created="Thu, 6 Sep 2012 04:09:13 +0200 (CEST)" level="">several corner cases not taken into account.</comment>
            
            <comment author="jeen" created="Thu, 6 Sep 2012 04:17:00 +0200 (CEST)" level="">Added additional test cases and fix for corner cases, revision 11949. </comment>
            
            <comment author="pansell" created="Thu, 6 Sep 2012 05:47:15 +0200 (CEST)" level="">The additional fix in 11949 resolves this issue for me.</comment>
            
            <comment author="jeen" created="Thu, 6 Sep 2012 06:01:35 +0200 (CEST)" level="">Last revision confirmed to fix the issue.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1090] Add vocabulary constants for owl:Thing and owl:Nothing in OWL class</title>
<link>http://www.openrdf.org/issues/browse/SES-1090</link>

    
        <description>For some reason, org.openrdf.model.vocabulary.OWL does not define constants for owl:Thing and owl:Nothing. These should be added.</description>
    
    
        <environment></environment>
    
        <key id="14041">SES-1090</key>
        <summary>Add vocabulary constants for owl:Thing and owl:Nothing in OWL class</summary>
        <type id="4">Improvement</type>
    
        <priority id="5">Trivial</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Wed, 5 Sep 2012 22:35:53 +0200 (CEST)</created>
    <updated>Wed, 5 Sep 2012 22:48:44 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.10</fixVersion>
                
            
        
    

    
        
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1086] Default logback loglevel should be INFO, is currently set to WARN</title>
<link>http://www.openrdf.org/issues/browse/SES-1086</link>

    
        <description></description>
    
    
        <environment></environment>
    
        <key id="14010">SES-1086</key>
        <summary>Default logback loglevel should be INFO, is currently set to WARN</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Mon, 27 Aug 2012 02:08:31 +0200 (CEST)</created>
    <updated>Tue, 30 Oct 2012 23:33:09 +0100 (CET)</updated>

    
        
        
            
            
                
                    <version>2.6.9</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.10</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Configuration</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1080] Buffered RDF handler that groups incoming triples by context/subject/predicate</title>
<link>http://www.openrdf.org/issues/browse/SES-1080</link>

    
        <description>An RDFHandler implementation that can be used as a wrapper and which groups incoming statements together on context, subject, and predicate would be a useful new feature. This could be used in combination with any of the existing RDFWriters to produce slightly more ordered RDF documents (where all triples about the same subject are grouped together). </description>
    
    
        <environment></environment>
    
        <key id="13960">SES-1080</key>
        <summary>Buffered RDF handler that groups incoming triples by context/subject/predicate</summary>
        <type id="2">New Feature</type>
    
        <priority id="4">Minor</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Wed, 15 Aug 2012 06:56:03 +0200 (CEST)</created>
    <updated>Wed, 15 Aug 2012 06:57:49 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.9</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Rio</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Wed, 15 Aug 2012 06:57:49 +0200 (CEST)" level="">implemented (rev 11926)</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1079] RDF/XML parser should report warning on datatypes starting with &apos;xsd:&apos;</title>
<link>http://www.openrdf.org/issues/browse/SES-1079</link>

    
        <description>A common mistake in (handwritten) RDF/XML is to specify the datatype of a literal using its prefixed name:&lt;br/&gt;
&lt;br/&gt;
&amp;nbsp;&amp;lt;foo:bar rdf:datatype=&amp;quot;xsd:string&amp;quot;&amp;gt;foobar&amp;lt;/foo:bar&amp;gt;&lt;br/&gt;
&lt;br/&gt;
However, while this is syntactically correct, it is intrepreted by the parser as meaning that the datatype URI is &apos;xsd:string&apos;, rather than &apos;&lt;a href=&quot;http://www.w3.org/2001/XMLSchema#string&quot;&gt;http://www.w3.org/2001/XMLSchema#string&lt;/a&gt;&apos;.&lt;br/&gt;
&lt;br/&gt;
The correct way to specify the datatype in RDF/XML is:&lt;br/&gt;
&lt;br/&gt;
&amp;nbsp;&amp;lt;foo:bar rdf:datatype=&amp;quot;&lt;a href=&quot;http://www.w3.org/2001/XMLSchema#string&quot;&gt;http://www.w3.org/2001/XMLSchema#string&lt;/a&gt;&amp;quot;&amp;gt;foobar&amp;lt;/foo:bar&amp;gt;&lt;br/&gt;
&lt;br/&gt;
It would be helpful if the parser, when running in VERIFY or NORMALIZE mode, would report a warning when it encounters datatype URIs that start with &apos;xsd&apos;. &lt;br/&gt;
&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="13950">SES-1079</key>
        <summary>RDF/XML parser should report warning on datatypes starting with &apos;xsd:&apos;</summary>
        <type id="4">Improvement</type>
    
        <priority id="4">Minor</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Sat, 11 Aug 2012 06:26:09 +0200 (CEST)</created>
    <updated>Mon, 13 Aug 2012 22:44:39 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.9</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Rio</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Sun, 12 Aug 2012 00:02:21 +0200 (CEST)" level="">Implemented in svn. Parser now reports a warning when encountering a datatype that starts with &apos;xsd&apos;. It performs this check when the parser is running in data verification mode and datatype handling is not set to IGNORE. </comment>
            
            <comment author="dwvisser" created="Sun, 12 Aug 2012 18:26:21 +0200 (CEST)" level="">Could you post some instructions about how I would go about configuring my Sesame server to issue these warnings?&lt;br/&gt;
&lt;br/&gt;
BTW, Thanks for doing this!&lt;br/&gt;
&lt;br/&gt;
</comment>
            
            <comment author="jeen" created="Sun, 12 Aug 2012 22:34:23 +0200 (CEST)" level="">Dale, no problem. And, you shouldn&apos;t need to change anything, the parsers used in the Sesame server run in the correct configuration by default. &lt;br/&gt;
&lt;br/&gt;
The Sesame server uses the parser configuration for RepositoryConnections. This is, by default, set to do syntax verification as well as datatype verification.</comment>
            
            <comment author="jeen" created="Mon, 13 Aug 2012 22:38:36 +0200 (CEST)" level="">Reopening to expand the check slightly: warn on any datatype URI that is not recognized as a supported XSD type.</comment>
            
            <comment author="jeen" created="Mon, 13 Aug 2012 22:44:39 +0200 (CEST)" level="">fixed in revision 11914</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10030">
            <name>Followup</name>
                
                
                    <outwardlinks description="is followup of">
                    
                        <issuelink>
                            <issuekey id="13941">SES-1078</issuekey>
                        </issuelink>
                    
                    </outwardlinks>
                
                
                
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1078] SPARQL query doesn&apos;t sort results when needing to cast numeric xsd:string to xsd:integer</title>
<link>http://www.openrdf.org/issues/browse/SES-1078</link>

    
        <description>I may have found a bug when sorting SPARQL queries on xsd:string data items that need to be converted to xsd:integer for the sorting. &lt;br/&gt;
&lt;br/&gt;
I&apos;ve attached a small RDF triples file with items deliberately out of order. When loaded into Sesame, and queried with the following query, it demonstrates the issue.&lt;br/&gt;
&lt;br/&gt;
PREFIX ida: &amp;lt;&lt;a href=&quot;http://ida.org/example/Section#&quot;&gt;http://ida.org/example/Section#&lt;/a&gt;&amp;gt;&lt;br/&gt;
PREFIX xsd: &amp;lt;&lt;a href=&quot;http://www.w3.org/2001/XMLSchema#&quot;&gt;http://www.w3.org/2001/XMLSchema#&lt;/a&gt;&amp;gt;&lt;br/&gt;
&lt;br/&gt;
SELECT DISTINCT ?num ?section WHERE {&lt;br/&gt;
&amp;lt;&lt;a href=&quot;http://ida.org/example/Section#Document&quot;&gt;http://ida.org/example/Section#Document&lt;/a&gt;&amp;gt; ida:contains ?section .&lt;br/&gt;
?section ida:section_num ?sectionNumber .&lt;br/&gt;
?sectionNumber ida:content ?num .&lt;br/&gt;
} ORDER BY xsd:integer(?num)&lt;br/&gt;
&lt;br/&gt;
The attached SPARQL/XML result file shows that the results are not being returned as expected. The appearance of the issue began when I switched from an RDF/XML data set from an N-Triples data set, but I think the input format is possibly a red herring here.&lt;br/&gt;
</description>
    
    
        <environment>Ubuntu 12.04, Tomcat 6, OpenJDK 6</environment>
    
        <key id="13941">SES-1078</key>
        <summary>SPARQL query doesn&apos;t sort results when needing to cast numeric xsd:string to xsd:integer</summary>
        <type id="1">Bug</type>
    
        <priority id="4">Minor</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="2">Won&apos;t Fix</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Fri, 10 Aug 2012 17:12:53 +0200 (CEST)</created>
    <updated>Sun, 12 Aug 2012 17:52:59 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.7</version>
                
                    <version>2.6.8</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>Query Engine</component>
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="dwvisser" created="Fri, 10 Aug 2012 17:13:24 +0200 (CEST)" level="">Data for reproducing the issue.</comment>
            
            <comment author="dwvisser" created="Fri, 10 Aug 2012 17:14:22 +0200 (CEST)" level="">Query result set returned when running the query in Workbench. Note that the order is the order that the triples were loaded, not the expected sort order.</comment>
            
            <comment author="jeen" created="Sat, 11 Aug 2012 06:05:48 +0200 (CEST)" level="">The problem is actually in the input RDF data. The RDF/XML file has this:&lt;br/&gt;
&lt;br/&gt;
&amp;nbsp;	&amp;lt;ida:content rdf:datatype=&amp;quot;xsd:string&amp;quot;&amp;gt;1&amp;lt;/ida:content&amp;gt;&lt;br/&gt;
&lt;br/&gt;
You cannot use a prefixed name for the datatype in RDF/XML. This should be the full URI:&lt;br/&gt;
&lt;br/&gt;
	&amp;lt;ida:content rdf:datatype=&amp;quot;&lt;a href=&quot;http://www.w3.org/2001/XMLSchema#string&quot;&gt;http://www.w3.org/2001/XMLSchema#string&lt;/a&gt;&amp;quot;&amp;gt;1&amp;lt;/ida:content&amp;gt;&lt;br/&gt;
&lt;br/&gt;
So, what happens is that your data is parsed with a literal with an unknown datatype &apos;xsd:string&apos;. This literal is then rejected by the integer cast function with an error (because it cannot cast a literal with an unknown datatype to integer). Which means the ordering fails and just silently returns results in random order.&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
</comment>
            
            <comment author="jeen" created="Sat, 11 Aug 2012 06:06:34 +0200 (CEST)" level="">It took me a while to figure this out as well. RDF/XML sucks :)</comment>
            
            <comment author="dwvisser" created="Sun, 12 Aug 2012 17:52:59 +0200 (CEST)" level="">Thanks, Jeen! I had no idea. This explains why the problem didn&apos;t occur when I used N-Triples earlier.</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10030">
            <name>Followup</name>
                
                
                
                
                
                    <inwardlinks description="is followed up by">
                    
                        <issuelink>
                            <issuekey id="13950">SES-1079</issuekey>
                        </issuelink>
                    
                    </inwardlinks>
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1077] GroupIterator should not evaluate entire subquery on initialize</title>
<link>http://www.openrdf.org/issues/browse/SES-1077</link>

    
        <description>&lt;br/&gt;
Causes evaluate() calls to block for a long time, defeating lazy iteration and query abort attempts.&lt;br/&gt;
&lt;br/&gt;
init should be moved to first call of hasNext() method.</description>
    
    
        <environment></environment>
    
        <key id="13940">SES-1077</key>
        <summary>GroupIterator should not evaluate entire subquery on initialize</summary>
        <type id="4">Improvement</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Fri, 10 Aug 2012 06:24:54 +0200 (CEST)</created>
    <updated>Fri, 10 Aug 2012 06:37:47 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.9</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1076] Support certain standard namespaces without having explicit declarations for them</title>
<link>http://www.openrdf.org/issues/browse/SES-1076</link>

    
        <description>Sesame&apos;s SPARQL engine currently needs explicitly defined namespace declarations for every qname in a query. It would be convenient if the engine would use default values for certain &apos;standard&apos; namespace prefixes, such as rdf, rdfs, owl, xsd, fn, and the sesame namespace.&lt;br/&gt;
&lt;br/&gt;
This can be easily dealt with in the PrefixDeclProcessor, by simply inserting these default namespaces (but only _if_ there is no explicitly defined namespace with the same value or prefix).&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="13933">SES-1076</key>
        <summary>Support certain standard namespaces without having explicit declarations for them</summary>
        <type id="4">Improvement</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Thu, 9 Aug 2012 00:34:00 +0200 (CEST)</created>
    <updated>Thu, 9 Aug 2012 22:44:45 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.9</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Query Engine</component>
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Thu, 9 Aug 2012 00:39:56 +0200 (CEST)" level="">implemented defaults for &apos;rdf&apos;, &apos;rdfs&apos;, &apos;sesame&apos;, &apos;owl&apos;, &apos;fn&apos; and &apos;xsd&apos;. These defaults are only set if the query itself does not specify either the prefix or the corresponding namespace value in its namespace declarations. </comment>
            
            <comment author="james" created="Thu, 9 Aug 2012 22:44:45 +0200 (CEST)" level="">The Turtle parser does something similar. See org.openrdf.rio.helpers.RDFParserBase and &lt;a href=&quot;http://www.w3.org/2011/rdfa-context/rdfa-1.1&quot;&gt;http://www.w3.org/2011/rdfa-context/rdfa-1.1&lt;/a&gt;.&lt;br/&gt;
&lt;br/&gt;
It might make sense to align the Initial Context for both Turtle and SPARQL parsers, although the &apos;fn&apos; and &apos;sesame&apos; space doesn&apos;t make as much sense in turtle.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1074] Context ignored in subselect query</title>
<link>http://www.openrdf.org/issues/browse/SES-1074</link>

    
        <description>It seems as if subselect query with specified context ignore the context and use default graph instead.&lt;br/&gt;
&lt;br/&gt;
Following queries provides different answers :&lt;br/&gt;
&lt;br/&gt;
SELECT (count(?s) as ?count) FROM &amp;lt;&lt;a href=&quot;http://www.ontotext.com/implicit&quot;&gt;http://www.ontotext.com/implicit&lt;/a&gt;&amp;gt; WHERE&lt;br/&gt;
{&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;	?s ?p ?o .  &lt;br/&gt;
}&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
SELECT * WHERE &lt;br/&gt;
{&lt;br/&gt;
	{																			&lt;br/&gt;
&amp;nbsp;&amp;nbsp;	         SELECT (count(?s) as ?count) FROM &amp;lt;&lt;a href=&quot;http://www.ontotext.com/implicit&quot;&gt;http://www.ontotext.com/implicit&lt;/a&gt;&amp;gt; WHERE&lt;br/&gt;
		 {&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;		    	?s ?p ?o .  &lt;br/&gt;
		 }&lt;br/&gt;
	} &lt;br/&gt;
}	&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="13931">SES-1074</key>
        <summary>Context ignored in subselect query</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="mareksurek">Marek Surek</reporter>
        
    

        
        <created>Wed, 8 Aug 2012 22:54:07 +0200 (CEST)</created>
    <updated>Thu, 9 Aug 2012 00:53:15 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.8</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.9</fixVersion>
                
            
        
    

    
        
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Thu, 9 Aug 2012 00:45:27 +0200 (CEST)" level="">The second query is actually syntactically illegal: you can not specify a dataset using FROM (NAMED) as part of a subselect. &lt;br/&gt;
&lt;br/&gt;
The bug here is that the query parser should throw an error rather than accept the query.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1071] Deprecate RDBMS Sail code and disable RDBMS-related tests</title>
<link>http://www.openrdf.org/issues/browse/SES-1071</link>

    
        <description>The Sesame RDBMS Sail will be deprecated. Code needs to be marked as such, and testsuites on the Postgres/MySQL backends can be disabled.</description>
    
    
        <environment></environment>
    
        <key id="13911">SES-1071</key>
        <summary>Deprecate RDBMS Sail code and disable RDBMS-related tests</summary>
        <type id="3">Task</type>
    
        <priority id="1">Blocker</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Mon, 6 Aug 2012 23:10:48 +0200 (CEST)</created>
    <updated>Wed, 12 Sep 2012 01:38:10 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.7.0</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>RDBMS Sail</component>
                
                    <component>Test suites</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Wed, 12 Sep 2012 01:38:10 +0200 (CEST)" level="">code deprecated and conformance tests all disabled, revision 11962.</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10030">
            <name>Followup</name>
                
                
                    <outwardlinks description="is followup of">
                    
                        <issuelink>
                            <issuekey id="13100">SES-923</issuekey>
                        </issuelink>
                    
                    </outwardlinks>
                
                
                
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1070] Improve streaming behavior of HTTPRepository</title>
<link>http://www.openrdf.org/issues/browse/SES-1070</link>

    
        <description>Currently, the HTTPRepository does a complete parse of a server response before passing the result on to the caller. This means that executing any operation with a large number of results (e.g. an export) over HTTP runs the risk of OutOfMemoryErrors at the client side, even when the user expects an iteration.&lt;br/&gt;
&lt;br/&gt;
To improve, the HTTPRepository should implement a strategy similar to the SPARQLRepository, which processes server responses in the background and can return results to the user _while processing_ the server response.</description>
    
    
        <environment></environment>
    
        <key id="13910">SES-1070</key>
        <summary>Improve streaming behavior of HTTPRepository</summary>
        <type id="4">Improvement</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="3">Duplicate</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Mon, 6 Aug 2012 22:28:43 +0200 (CEST)</created>
    <updated>Thu, 16 Aug 2012 02:37:36 +0200 (CEST)</updated>

    
        
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>HTTPRepository</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
    

    



    <issuelinks>
    
        <issuelinktype id="10000">
            <name>Duplicate</name>
                
                
                    <outwardlinks description="duplicates">
                    
                        <issuelink>
                            <issuekey id="13870">SES-1066</issuekey>
                        </issuelink>
                    
                    </outwardlinks>
                
                
                
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1069] CLONE -Export Repository Data To Binary Format - Unsupported yet</title>
<link>http://www.openrdf.org/issues/browse/SES-1069</link>

    
        <description>Tomcat 6.0 container&lt;br/&gt;
&lt;br/&gt;
Export Repository --&amp;gt; Download format -&amp;gt; Binary RDF&lt;br/&gt;
&lt;br/&gt;
Click on Download produces the following error:&lt;br/&gt;
&lt;br/&gt;
-----------------------------------------------------------------------------&lt;br/&gt;
&lt;br/&gt;
HTTP Status 500 -&lt;br/&gt;
&lt;br/&gt;
type Exception report&lt;br/&gt;
&lt;br/&gt;
message&lt;br/&gt;
&lt;br/&gt;
description The server encountered an internal error () that prevented it from fulfilling this request.&lt;br/&gt;
&lt;br/&gt;
exception&lt;br/&gt;
&lt;br/&gt;
java.lang.UnsupportedOperationException&lt;br/&gt;
	org.openrdf.rio.binary.BinaryRDFWriterFactory.getWriter(BinaryRDFWriterFactory.java:40)&lt;br/&gt;
	org.openrdf.workbench.commands.ExportServlet.service(ExportServlet.java:50)&lt;br/&gt;
	org.openrdf.workbench.base.TransformationServlet.service(TransformationServlet.java:73)&lt;br/&gt;
	org.openrdf.workbench.base.BaseServlet.service(BaseServlet.java:40)&lt;br/&gt;
	org.openrdf.workbench.proxy.ProxyRepositoryServlet.service(ProxyRepositoryServlet.java:93)&lt;br/&gt;
	org.openrdf.workbench.proxy.WorkbenchServlet.service(WorkbenchServlet.java:131)&lt;br/&gt;
	org.openrdf.workbench.proxy.WorkbenchServlet.service(WorkbenchServlet.java:90)&lt;br/&gt;
	org.openrdf.workbench.proxy.WorkbenchGateway.service(WorkbenchGateway.java:109)&lt;br/&gt;
	org.openrdf.workbench.base.BaseServlet.service(BaseServlet.java:40)&lt;br/&gt;
	org.openrdf.workbench.proxy.CookieCacheControlFilter.doFilter(CookieCacheControlFilter.java:52)</description>
    
    
        <environment>Windows-7 (64 bit version)</environment>
    
        <key id="13900">SES-1069</key>
        <summary>CLONE -Export Repository Data To Binary Format - Unsupported yet</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="3">Duplicate</resolution>
        
    
        
        <assignee username="arjohn">Arjohn Kampman</assignee>
        
    

    
        
        <reporter username="dwvisser">Dale W. Visser</reporter>
        
    

        
        <created>Sat, 4 Aug 2012 19:50:44 +0200 (CEST)</created>
    <updated>Sun, 5 Aug 2012 03:33:52 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.5.1</version>
                
            
        
    

    
        
        
    

    
        
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="dwvisser" created="Sat, 4 Aug 2012 19:53:03 +0200 (CEST)" level="">Seen in Linux, using Sesame/Workbench v2.6.7. Other formats are exporting without issue.&lt;br/&gt;
&lt;br/&gt;
HTTP Status 500 -&lt;br/&gt;
&lt;br/&gt;
type Exception report&lt;br/&gt;
&lt;br/&gt;
message&lt;br/&gt;
&lt;br/&gt;
description The server encountered an internal error () that prevented it from fulfilling this request.&lt;br/&gt;
&lt;br/&gt;
exception&lt;br/&gt;
&lt;br/&gt;
java.lang.UnsupportedOperationException&lt;br/&gt;
	org.openrdf.rio.binary.BinaryRDFWriterFactory.getWriter(BinaryRDFWriterFactory.java:40)&lt;br/&gt;
	org.openrdf.workbench.commands.ExportServlet.service(ExportServlet.java:50)&lt;br/&gt;
	org.openrdf.workbench.base.TransformationServlet.service(TransformationServlet.java:73)&lt;br/&gt;
	org.openrdf.workbench.base.BaseServlet.service(BaseServlet.java:40)&lt;br/&gt;
	org.openrdf.workbench.proxy.ProxyRepositoryServlet.service(ProxyRepositoryServlet.java:93)&lt;br/&gt;
	org.openrdf.workbench.proxy.WorkbenchServlet.service(WorkbenchServlet.java:131)&lt;br/&gt;
	org.openrdf.workbench.proxy.WorkbenchServlet.service(WorkbenchServlet.java:90)&lt;br/&gt;
	org.openrdf.workbench.proxy.WorkbenchGateway.service(WorkbenchGateway.java:109)&lt;br/&gt;
	org.openrdf.workbench.base.BaseServlet.service(BaseServlet.java:40)&lt;br/&gt;
	org.openrdf.workbench.proxy.CookieCacheControlFilter.doFilter(CookieCacheControlFilter.java:52)&lt;br/&gt;
note The full stack trace of the root cause is available in the Apache Tomcat/6.0.35 logs.&lt;br/&gt;
&lt;br/&gt;
Apache Tomcat/6.0.35</comment>
            
            <comment author="dwvisser" created="Sat, 4 Aug 2012 21:08:40 +0200 (CEST)" level="">Just upgraded my system to 2.6.8, and confirmed this issue still reproduces:&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
System Information&lt;br/&gt;
Application Information&lt;br/&gt;
Application Name	OpenRDF Workbench&lt;br/&gt;
Version	2.6.8&lt;br/&gt;
Runtime Information&lt;br/&gt;
Operating System	Linux 3.2.0-27-generic (i386)&lt;br/&gt;
Java Runtime	Sun Microsystems Inc. OpenJDK Client VM (1.6.0_24)&lt;br/&gt;
Process User	tomcat6&lt;br/&gt;
Memory&lt;br/&gt;
Used	73 MB&lt;br/&gt;
Maximum	126 MB&lt;br/&gt;
&lt;br/&gt;
--&lt;br/&gt;
&lt;br/&gt;
HTTP Status 500 -&lt;br/&gt;
&lt;br/&gt;
type Exception report&lt;br/&gt;
&lt;br/&gt;
message&lt;br/&gt;
&lt;br/&gt;
description The server encountered an internal error () that prevented it from fulfilling this request.&lt;br/&gt;
&lt;br/&gt;
exception&lt;br/&gt;
&lt;br/&gt;
java.lang.UnsupportedOperationException&lt;br/&gt;
	org.openrdf.rio.binary.BinaryRDFWriterFactory.getWriter(BinaryRDFWriterFactory.java:40)&lt;br/&gt;
	org.openrdf.workbench.commands.ExportServlet.service(ExportServlet.java:50)&lt;br/&gt;
	org.openrdf.workbench.base.TransformationServlet.service(TransformationServlet.java:73)&lt;br/&gt;
	org.openrdf.workbench.base.BaseServlet.service(BaseServlet.java:40)&lt;br/&gt;
	org.openrdf.workbench.proxy.ProxyRepositoryServlet.service(ProxyRepositoryServlet.java:93)&lt;br/&gt;
	org.openrdf.workbench.proxy.WorkbenchServlet.service(WorkbenchServlet.java:131)&lt;br/&gt;
	org.openrdf.workbench.proxy.WorkbenchServlet.service(WorkbenchServlet.java:90)&lt;br/&gt;
	org.openrdf.workbench.proxy.WorkbenchGateway.service(WorkbenchGateway.java:109)&lt;br/&gt;
	org.openrdf.workbench.base.BaseServlet.service(BaseServlet.java:40)&lt;br/&gt;
	org.openrdf.workbench.proxy.CookieCacheControlFilter.doFilter(CookieCacheControlFilter.java:52)&lt;br/&gt;
note The full stack trace of the root cause is available in the Apache Tomcat/6.0.35 logs.&lt;br/&gt;
&lt;br/&gt;
Apache Tomcat/6.0.35</comment>
            
            <comment author="jeen" created="Sun, 5 Aug 2012 03:33:52 +0200 (CEST)" level="">Marking this as a duplicate, further tracking will happen in  original issue (&lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-840&quot; title=&quot;Export Repository Data To Binary Format - Unsupported yet&quot;&gt;&lt;strike&gt;SES-840&lt;/strike&gt;&lt;/a&gt;). Rescheduled for 2.6.9 release.&lt;br/&gt;
&lt;br/&gt;
By the way Dale, you should be able to comment on that issue as well, without having to clone it. It&apos;s not a problem that you did, just thought I&apos;d point it out. </comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10000">
            <name>Duplicate</name>
                
                
                    <outwardlinks description="duplicates">
                    
                        <issuelink>
                            <issuekey id="12620">SES-840</issuekey>
                        </issuelink>
                    
                    </outwardlinks>
                
                
                
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1067] Trying to HTTP DELETE a repository gives a 500 Method Not Allowed Error</title>
<link>http://www.openrdf.org/issues/browse/SES-1067</link>

    
        <description>When trying to issue a HTTP DELETE (with Accept: */*) to a repository URL e.g. &lt;a href=&quot;http://localhost:8080/openrdf-sesame/myrepo&quot;&gt;http://localhost:8080/openrdf-sesame/myrepo&lt;/a&gt; which according to the documentation at &lt;a href=&quot;http://www.openrdf.org/doc/sesame2/system/ch08.html#d0e320&quot;&gt;http://www.openrdf.org/doc/sesame2/system/ch08.html#d0e320&lt;/a&gt; is the way to delete a repository I receive a HTTP 500 Method Not Allowed error&lt;br/&gt;
&lt;br/&gt;
Besides the fact that this is the wrong HTTP error code for method not allowed is there any obvious reason why this wouldn&apos;t work&lt;br/&gt;
&lt;br/&gt;
I am using Sesame 2.6.4 and will try upgrading to see if that resolves the issue</description>
    
    
        <environment>Windows 7 x64, Tomcat 7</environment>
    
        <key id="13880">SES-1067</key>
        <summary>Trying to HTTP DELETE a repository gives a 500 Method Not Allowed Error</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="5">Cannot Reproduce</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="rvesse">Rob Vesse</reporter>
        
    

        
        <created>Fri, 27 Jul 2012 19:54:43 +0200 (CEST)</created>
    <updated>Mon, 30 Jul 2012 02:53:21 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.4</version>
                
            
        
    

    
        
        
    

    
        
        
            
            
                
                    <component>HTTP Server</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="rvesse" created="Fri, 27 Jul 2012 20:02:24 +0200 (CEST)" level="">Works fine with 2.6.8 so feel free to mark as fixed or not a bug&lt;br/&gt;
&lt;br/&gt;
Wwas this ability only recently introduced into the API?  if so could you please amend the documentation to state which version this became available from.</comment>
            
            <comment author="jeen" created="Mon, 30 Jul 2012 02:52:31 +0200 (CEST)" level="">It was indeed only recently introduced, as part of a fix for issue &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-880&quot; title=&quot;Repository manager should delete storage files are removing a repository.&quot;&gt;&lt;strike&gt;SES-880&lt;/strike&gt;&lt;/a&gt; (resolved in Sesame 2.6.6). &lt;br/&gt;
&lt;br/&gt;
</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1063] integer division should set higher scale </title>
<link>http://www.openrdf.org/issues/browse/SES-1063</link>

    
        <description>Currently, in sparql, doing&lt;br/&gt;
&lt;br/&gt;
select ?v where { bind( 1/3 as ?v) }&lt;br/&gt;
&lt;br/&gt;
results in:&lt;br/&gt;
&lt;br/&gt;
&amp;nbsp;&amp;quot;0&amp;quot;^^xsd:decimal &lt;br/&gt;
&lt;br/&gt;
This is caused by the fact that MathUtil uses the input scales as defining the scale of the output decimal. Since we are dividing integers, the scale is zero, by definition. &lt;br/&gt;
An improvement would be to explicitly set the scale on divisions that result in non-terminating decimal sequences. An arbitrary number that seems suitable is 24 digits.&lt;br/&gt;
&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="13841">SES-1063</key>
        <summary>integer division should set higher scale </summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="jeen">Jeen Broekstra</reporter>
        
    

        
        <created>Thu, 19 Jul 2012 02:31:46 +0200 (CEST)</created>
    <updated>Mon, 23 Jul 2012 22:35:55 +0200 (CEST)</updated>

    
        
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.9</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Mon, 23 Jul 2012 22:35:55 +0200 (CEST)" level="">Reclassified as a bug after all, since the xsd spec has this to say about xsd:decimal precision:&lt;br/&gt;
&lt;br/&gt;
&amp;quot;All - minimally conforming-  processors - must-  support decimal numbers with a minimum of 18 decimal digits (i.e., with a - totalDigits-  of 18). However, - minimally conforming-  processors - may-  set an  application-defined limit on the maximum number of decimal digits they are prepared to support, in which case that application-defined maximum &lt;br/&gt;
number - must-  be clearly documented. &amp;quot;</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1062] IllegalArgumentException: timeout value is negative</title>
<link>http://www.openrdf.org/issues/browse/SES-1062</link>

    
        <description>We also see some cases of uncaught IllegalArgumentExceptions in the MemoryStore sync thread:&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
As per &lt;a href=&quot;http://sourceforge.net/mailarchive/message.php?msg_id=29558521&quot;&gt;http://sourceforge.net/mailarchive/message.php?msg_id=29558521&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
ERROR 11:13:39,490 [Thread-5]  STDERR Exception in thread &amp;quot;MemoryStore snapshot cleanup&amp;quot;&lt;br/&gt;
ERROR 11:13:39,490 [Thread-5]  STDERR java.lang.IllegalArgumentException: timeout value is negative&lt;br/&gt;
ERROR 11:13:39,490 [Thread-5]  STDERR at java.lang.Object.wait(Native Method)&lt;br/&gt;
ERROR 11:13:39,491 [Thread-5]  STDERR at info.aduna.concurrent.locks.LockManager.waitForActiveLocks(LockManager.java:126)&lt;br/&gt;
ERROR 11:13:39,491 [Thread-5]  STDERR at info.aduna.concurrent.locks.AbstractReadWriteLockManager.waitForActiveReaders(AbstractReadWriteLockManager.java:95)&lt;br/&gt;
ERROR 11:13:39,491 [Thread-5]  STDERR at info.aduna.concurrent.locks.ReadPrefReadWriteLockManager.getWriteLock(ReadPrefReadWriteLockManager.java:113)&lt;br/&gt;
ERROR 11:13:39,491 [Thread-5]  STDERR at org.openrdf.sail.memory.MemoryStore.cleanSnapshots(MemoryStore.java:916)&lt;br/&gt;
ERROR 11:13:39,491 [Thread-5]  STDERR at org.openrdf.sail.memory.MemoryStore$2.run(MemoryStore.java:969)&lt;br/&gt;
ERROR 11:13:39,491 [Thread-5]  STDERR at java.lang.Thread.run(Thread.java:662)&lt;br/&gt;
</description>
    
    
        <environment></environment>
    
        <key id="13840">SES-1062</key>
        <summary>IllegalArgumentException: timeout value is negative</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="james">James Leigh</assignee>
        
    

    
        
        <reporter username="james">James Leigh</reporter>
        
    

        
        <created>Wed, 18 Jul 2012 18:52:53 +0200 (CEST)</created>
    <updated>Wed, 18 Jul 2012 19:36:14 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.7</version>
                
                    <version>2.6.8</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.9</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>Memory Sail</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="james" created="Wed, 18 Jul 2012 19:36:14 +0200 (CEST)" level="">Revision 11899 checks to ensure the timeout value does not go over the max int value and increases the initial timeout from 1 second to 10 seconds before trying to recover from a potential dead lock.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
<item>

    







<title>[SES-1060] REGRESSION: SameTermFilterOptimizer throws AssertionError if Term Used in UNION</title>
<link>http://www.openrdf.org/issues/browse/SES-1060</link>

    
        <description>The following query fails to evaluate when assertions are enabled (-ea).&lt;br/&gt;
&lt;br/&gt;
		StringBuilder query = new StringBuilder();&lt;br/&gt;
		query.append(&amp;quot;PREFIX foaf:&amp;lt;&lt;a href=&quot;http://xmlns.com/foaf/0.1/&quot;&gt;http://xmlns.com/foaf/0.1/&lt;/a&gt;&amp;gt;\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;SELECT * {\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;    {\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;        ?sameTerm foaf:mbox ?mbox\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;        FILTER sameTerm(?sameTerm,$william)\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;    } UNION {\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;        ?x foaf:knows ?sameTerm\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;        FILTER sameTerm(?sameTerm,$william)\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;    }\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;}&amp;quot;);&lt;br/&gt;
&lt;br/&gt;
&lt;br/&gt;
For what it&apos;s worth: this issue _only_ affects running with assertions enabled. When assertions are not enabled, the query is correctly optimized and evaluated. &lt;br/&gt;
&lt;br/&gt;
The reason is that the offending assertion simply checks that a new binding does not overwrite an existing binding in the bindingset, but in this case, the new binding has the exact same value as the existing binding, so an overwrite does not cause an actual problem. Still, the assertion is correct, and we should check that we don&apos;t overwrite before adding the binding.</description>
    
    
        <environment></environment>
    
        <key id="13820">SES-1060</key>
        <summary>REGRESSION: SameTermFilterOptimizer throws AssertionError if Term Used in UNION</summary>
        <type id="1">Bug</type>
    
        <priority id="2">Critical</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="james">James Leigh</reporter>
        
    

        
        <created>Thu, 12 Jul 2012 20:10:22 +0200 (CEST)</created>
    <updated>Tue, 7 Aug 2012 03:18:16 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.7</version>
                
                    <version>2.6.8</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.9</fixVersion>
                
            
        
    

    
        
        
            
            
                
                    <component>SPARQL</component>
                
            
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="james" created="Thu, 12 Jul 2012 20:30:18 +0200 (CEST)" level="">Resolved in revision 11885 in 2.6 branch.</comment>
            
            <comment author="jeen" created="Thu, 12 Jul 2012 22:29:19 +0200 (CEST)" level="">reviewed, fix looks correct, tests all greenline, marking resolved. </comment>
            
            <comment author="jeen" created="Thu, 12 Jul 2012 23:31:40 +0200 (CEST)" level="">Reopening, because the fix turns out to cause (unexpected) test failures in the MySQL backend, various tests in org.openrdf.sail.rdbms.MySQLStoreTest now fail. Probable cause is that the RDBMS optimizer chokes on the fact that the filter clause is left in the query model.</comment>
            
            <comment author="jeen" created="Fri, 13 Jul 2012 00:57:27 +0200 (CEST)" level="">Possible alternative fix is to regress back to the solution implemented in in &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-1025&quot; title=&quot;SameTermFilterOptimizer should not inline same variable more than once&quot;&gt;&lt;strike&gt;SES-1025&lt;/strike&gt;&lt;/a&gt;, but add a check in bindVar: only add the variable binding to the binding set if it isn&apos;t already present.</comment>
            
            <comment author="jeen" created="Fri, 13 Jul 2012 01:08:47 +0200 (CEST)" level="">fixed in revision 11891.</comment>
            
            <comment author="james" created="Fri, 13 Jul 2012 01:26:19 +0200 (CEST)" level="">The following query should never produce a result with ?opt1 bound. However, in branch/2.6 it currently does.&lt;br/&gt;
&lt;br/&gt;
		query.append(&amp;quot;SELECT * {\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;    {\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;        ex:a ?p ?prop1\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;        FILTER (?p = ex:prop1)\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;    } UNION {\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;          ?s ex:p ex:A ; &amp;quot; );&lt;br/&gt;
		query.append(&amp;quot;          { &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;              { &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;                 ?s ?p ?l .&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;                 FILTER(?p = rdfs:label) &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;              } &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;              OPTIONAL { &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;                 ?s ?p ?opt1 . &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;                 FILTER (?p = ex:prop1) &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;              } &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;              OPTIONAL { &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;                 ?s ?p ?opt2 . &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;                 FILTER (?p = ex:prop2) &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;              } &amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;          }&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;    }\n&amp;quot;);&lt;br/&gt;
		query.append(&amp;quot;}&amp;quot;);</comment>
            
            <comment author="jeen" created="Mon, 16 Jul 2012 00:27:18 +0200 (CEST)" level="">Hm. Cause is that the first filter is inlined with ?p = prop1. The second filter is not inlined because it produces a value clash, but the third filter (in the first optional clause) _is_ inlined again. &lt;br/&gt;
&lt;br/&gt;
The value clash should be prevented because the previous binding should not play a role if it&apos;s set in the other argument of a union. &lt;br/&gt;
&lt;br/&gt;
</comment>
            
            <comment author="james" created="Mon, 6 Aug 2012 15:07:31 +0200 (CEST)" level="">Resolved in revision 11906 by forking the optimizer for RDBMS</comment>
            
            <comment author="jeen" created="Mon, 6 Aug 2012 23:47:45 +0200 (CEST)" level="">Unfortunately, current fix makes the following test fail:&lt;br/&gt;
&lt;br/&gt;
org.openrdf.query.parser.sparql.MemoryComplexSPARQLQueryTest.testSameTermRepeatInUnionAndOptional&lt;br/&gt;
&lt;br/&gt;
</comment>
            
            <comment author="james" created="Tue, 7 Aug 2012 03:18:16 +0200 (CEST)" level="">Well that was embarrassing. Thanks Jeen, the test now passes.</comment>
            
        </comments>
    
    

    



    <issuelinks>
    
        <issuelinktype id="10010">
            <name>Cause</name>
                
                
                
                
                
                    <inwardlinks description="is caused by">
                    
                        <issuelink>
                            <issuekey id="13610">SES-1025</issuekey>
                        </issuelink>
                    
                    </inwardlinks>
                
                
        </issuelinktype>
    
    </issuelinks>


    
    
    

</item>
    
<item>

    







<title>[SES-1059] Shutting down and re-initializing a remote repository causes an IllegalStateException</title>
<link>http://www.openrdf.org/issues/browse/SES-1059</link>

    
        <description>The following code:&lt;br/&gt;
&lt;br/&gt;
		Repository rep = ...&lt;br/&gt;
		RepositoryConnection conn = rep.getConnection();&lt;br/&gt;
		conn.clearNamespaces();&lt;br/&gt;
		conn.commit();&lt;br/&gt;
		rep.shutDown();&lt;br/&gt;
		rep.initialize();&lt;br/&gt;
		conn = rep.getConnection();&lt;br/&gt;
		conn.getNamespaces().hasNext();&lt;br/&gt;
&lt;br/&gt;
causes this exception when used with a remote repository:&lt;br/&gt;
&lt;br/&gt;
java.lang.IllegalStateException: Connection factory has been shutdown.&lt;br/&gt;
	at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:463)&lt;br/&gt;
	at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnectionWithTimeout(MultiThreadedHttpConnectionManager.java:416)&lt;br/&gt;
	at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:153)&lt;br/&gt;
	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)&lt;br/&gt;
	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)&lt;br/&gt;
	at org.openrdf.http.client.HTTPClient.getTupleQueryResult(HTTPClient.java:1136)&lt;br/&gt;
	at org.openrdf.http.client.HTTPClient.getNamespaces(HTTPClient.java:918)&lt;br/&gt;
	at org.openrdf.http.client.HTTPClient.getNamespaces(HTTPClient.java:899)&lt;br/&gt;
	at org.openrdf.repository.http.HTTPRepositoryConnection.getNamespaces(HTTPRepositoryConnection.java:387)&lt;br/&gt;
&lt;br/&gt;
Which sounds like it is connected to &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-999&quot; title=&quot;Improve handling of repositories that have been shutdown in the RepositoryManager&quot;&gt;&lt;strike&gt;SES-999&lt;/strike&gt;&lt;/a&gt;</description>
    
    
        <environment></environment>
    
        <key id="13810">SES-1059</key>
        <summary>Shutting down and re-initializing a remote repository causes an IllegalStateException</summary>
        <type id="1">Bug</type>
    
        <priority id="3">Major</priority>
    
        <status id="5">Resolved</status>
        
        <resolution id="1">Fixed</resolution>
        
    
        
        <assignee username="jeen">Jeen Broekstra</assignee>
        
    

    
        
        <reporter username="bazbishop">Barry Bishop</reporter>
        
    

        
        <created>Wed, 11 Jul 2012 01:35:30 +0200 (CEST)</created>
    <updated>Wed, 11 Jul 2012 02:53:25 +0200 (CEST)</updated>

    
        
        
            
            
                
                    <version>2.6.7</version>
                
            
        
    

    
        
        
            
            
                
                    <fixVersion>2.6.8</fixVersion>
                
            
        
    

    
        
        
    

    
    
        <due></due>
    
    
        <votes>0</votes>
    
    

    
    
        <comments>
            
            <comment author="jeen" created="Wed, 11 Jul 2012 02:20:17 +0200 (CEST)" level="">Good catch. it&apos;s not related to &lt;a href=&quot;http://www.openrdf.org/issues/browse/SES-999&quot; title=&quot;Improve handling of repositories that have been shutdown in the RepositoryManager&quot;&gt;&lt;strike&gt;SES-999&lt;/strike&gt;&lt;/a&gt; as far as I can see. The problem is that HTTPClient is set in the constructor. On shutdown() the HTTPClient is also shutdown, but then is not reinitialized when you invoke initialize on the HTTPRepository. Fix is fairly easy I think: move creation of the HTTPClient to the initializeInternal method. </comment>
            
            <comment author="jeen" created="Wed, 11 Jul 2012 02:26:03 +0200 (CEST)" level="">Spoke too soon: that may be problematic in that several methods assume the httpclient is non-null, even before initialization.</comment>
            
            <comment author="jeen" created="Wed, 11 Jul 2012 02:53:25 +0200 (CEST)" level="">resolved by moving httpclient.shutDown call to the object finalizer.</comment>
            
        </comments>
    
    

    




    
    
    

</item>
    
</channel>
</rss>  

