[jira] [Created] (JENA-556) serviceURI should allow sparql endpoints running on port other that 80

2013-10-04 Thread Atharva Patel (JIRA) 
Atharva Patel created JENA-556:
--

 Summary: serviceURI should allow sparql endpoints running on port 
other that 80
 Key: JENA-556
 URL: https://issues.apache.org/jira/browse/JENA-556
 Project: Apache Jena
  Issue Type: Improvement
Affects Versions: TDB 1.0.0
Reporter: Atharva Patel


While trying to do simple query operation like this:
{code:java}
String sparqlEndpoint = "http://192.168.1.100:8890/sparql";;
String queryString ="...";
QueryExecution queryExecution = new QueryEngineHTTP(sparqlEndpoint, 
queryString);
{code}

It gives exception like this:
Caused by: HttpException: -1
at 
com.hp.hpl.jena.sparql.engine.http.HttpQuery.execGet(HttpQuery.java:340)
at com.hp.hpl.jena.sparql.engine.http.HttpQuery.exec(HttpQuery.java:276)
at 
com.hp.hpl.jena.sparql.engine.http.QueryEngineHTTP.execSelect(QueryEngineHTTP.java:346)

Caused by: java.net.UnknownHostException: 192.168.1.100:8890: nodename nor 
servname provided, or not known
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:866)
at 
java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1258)
at java.net.InetAddress.getAllByName0(InetAddress.java:1211)
at java.net.InetAddress.getAllByName(InetAddress.java:1127)
at java.net.InetAddress.getAllByName(InetAddress.java:1063)
at 
org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.resolveHostname(DefaultClientConnectionOperator.java:278)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:162)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:641)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at 
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at 
org.apache.http.impl.client.DecompressingHttpClient.execute(DecompressingHttpClient.java:130)
at 
org.apache.http.impl.client.DecompressingHttpClient.execute(DecompressingHttpClient.java:116)
at org.apache.jena.riot.web.HttpOp.exec(HttpOp.java:1011)
at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:291)
at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:353)
at 
com.hp.hpl.jena.sparql.engine.http.HttpQuery.execGet(HttpQuery.java:326)
... 20 more

The issue seems to be the way Jena tries to parse the serviceURI internally 
where there is likely to be a strong assumption that port number will never be 
passed by the user of this API.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (JENA-553) Handling of WITH keyword in SPARQL UPDATE seems to broken in Fuseki 1.0.0.

2013-10-04 Thread Hudson (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786564#comment-13786564
 ] 

Hudson commented on JENA-553:
-

ABORTED: Integrated in Jena_Development_Test #981 (See 
[https://builds.apache.org/job/Jena_Development_Test/981/])
JENA-553 : Reimplment DatasetGraphAltDefaultGraph

And also force DatasetGraph implementations to provide addGraph/removeGraph. 
(andy: rev 1529265)
* 
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/core/DatasetGraphAltDefaultGraph.java
* 
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/core/DatasetGraphBase.java
* 
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/core/DatasetGraphCollection.java
* 
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/GraphStoreNull.java
* 
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateEngineWorker.java


> Handling of WITH keyword in SPARQL UPDATE seems to broken in Fuseki 1.0.0.
> --
>
> Key: JENA-553
> URL: https://issues.apache.org/jira/browse/JENA-553
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 2.11.0, Fuseki 1.0.0
>Reporter: Michael Brunnbauer
>
> This does not generate the triple with "test1" as object:
> {noformat}
> drop graph ;
> insert data { graph  { _:b0  "test" }};
> WITH 
> DELETE { ?s ?p "test" }
> INSERT { ?s ?p "test1" }
> WHERE { ?s ?p "test" }
> {noformat}
> But this does (without WITH on default graph):
> {noformat}
> drop DEFAULT;
> insert data { _:b0  "test" };
> DELETE { ?s ?p "test" }
> INSERT { ?s ?p "test1" }
> WHERE { ?s ?p "test" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (JENA-553) Handling of WITH keyword in SPARQL UPDATE seems to broken in Fuseki 1.0.0.

2013-10-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786517#comment-13786517
 ] 

ASF subversion and git services commented on JENA-553:
--

Commit 1529265 from [~andy.seaborne] in branch 'jena/trunk'
[ https://svn.apache.org/r1529265 ]

JENA-553 : Reimplment DatasetGraphAltDefaultGraph

And also force DatasetGraph implementations to provide addGraph/removeGraph.

> Handling of WITH keyword in SPARQL UPDATE seems to broken in Fuseki 1.0.0.
> --
>
> Key: JENA-553
> URL: https://issues.apache.org/jira/browse/JENA-553
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 2.11.0, Fuseki 1.0.0
>Reporter: Michael Brunnbauer
>
> This does not generate the triple with "test1" as object:
> {noformat}
> drop graph ;
> insert data { graph  { _:b0  "test" }};
> WITH 
> DELETE { ?s ?p "test" }
> INSERT { ?s ?p "test1" }
> WHERE { ?s ?p "test" }
> {noformat}
> But this does (without WITH on default graph):
> {noformat}
> drop DEFAULT;
> insert data { _:b0  "test" };
> DELETE { ?s ?p "test" }
> INSERT { ?s ?p "test1" }
> WHERE { ?s ?p "test" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (JENA-553) Handling of WITH keyword in SPARQL UPDATE seems to broken in Fuseki 1.0.0.

2013-10-04 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786512#comment-13786512
 ] 

Andy Seaborne commented on JENA-553:


This is a better approach: it catches all graph level operations.  I'll commit 
this to the code base.

{noformat}
static class DatasetGraphAltDefaultGraph extends DatasetGraphCollection {
private Graph defaultGraph ;
private final DatasetGraph dsg ;

public DatasetGraphAltDefaultGraph(DatasetGraph dsg, Graph 
defaultGraph) {  
this.defaultGraph = defaultGraph ;
this.dsg = dsg ;
}

@Override
public Iterator listGraphNodes() {
return dsg.listGraphNodes() ;
}

@Override
public Graph getDefaultGraph() {
return defaultGraph ;
}

@Override
public Graph getGraph(Node graphNode) {
return dsg.getGraph(graphNode) ;
}

@Override
public void addGraph(Node graphName, Graph graph) { 
dsg.addGraph(graphName, graph); }

@Override
public void removeGraph(Node graphName)   { 
dsg.removeGraph(graphName); }
}
{noformat}

> Handling of WITH keyword in SPARQL UPDATE seems to broken in Fuseki 1.0.0.
> --
>
> Key: JENA-553
> URL: https://issues.apache.org/jira/browse/JENA-553
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 2.11.0, Fuseki 1.0.0
>Reporter: Michael Brunnbauer
>
> This does not generate the triple with "test1" as object:
> {noformat}
> drop graph ;
> insert data { graph  { _:b0  "test" }};
> WITH 
> DELETE { ?s ?p "test" }
> INSERT { ?s ?p "test1" }
> WHERE { ?s ?p "test" }
> {noformat}
> But this does (without WITH on default graph):
> {noformat}
> drop DEFAULT;
> insert data { _:b0  "test" };
> DELETE { ?s ?p "test" }
> INSERT { ?s ?p "test1" }
> WHERE { ?s ?p "test" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (JENA-553) Handling of WITH keyword in SPARQL UPDATE seems to broken in Fuseki 1.0.0.

2013-10-04 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/JENA-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786271#comment-13786271
 ] 

Andy Seaborne commented on JENA-553:


Here is an alternative implementation of {{DatasetGraphAltDefaultGraph}} that 
copies and changes the structure of the dataset, hence avoiding all the 
problems of consistently intercepting methods.

However, it requires {{listGraphNodes}} which is potentially expensive. As a 
common case will be to access and change just one of the named  graph, finding 
all graphs is potentially expensive for no real value.  Better would be a 
{{DatasetGraph}} that derives from {{DatasetGraphCollection}} (as does 
{{DatasetGraphMap}}).

{noformat}
static class DatasetGraphAltDefaultGraph extends DatasetGraphMap
{
public DatasetGraphAltDefaultGraph(DatasetGraph dsg, Graph dftGraph) {
super(dftGraph) ;
Iterator gNames = dsg.listGraphNodes() ;
while(gNames.hasNext()) {
Node gn = gNames.next() ;
addGraph(gn, dsg.getGraph(gn)) ;
}
}
} 
{noformat}

> Handling of WITH keyword in SPARQL UPDATE seems to broken in Fuseki 1.0.0.
> --
>
> Key: JENA-553
> URL: https://issues.apache.org/jira/browse/JENA-553
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 2.11.0, Fuseki 1.0.0
>Reporter: Michael Brunnbauer
>
> This does not generate the triple with "test1" as object:
> {noformat}
> drop graph ;
> insert data { graph  { _:b0  "test" }};
> WITH 
> DELETE { ?s ?p "test" }
> INSERT { ?s ?p "test1" }
> WHERE { ?s ?p "test" }
> {noformat}
> But this does (without WITH on default graph):
> {noformat}
> drop DEFAULT;
> insert data { _:b0  "test" };
> DELETE { ?s ?p "test" }
> INSERT { ?s ?p "test1" }
> WHERE { ?s ?p "test" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (JENA-555) Deprecate StageGenerators prior to removal.

2013-10-04 Thread Andy Seaborne (JIRA) 
Andy Seaborne created JENA-555:
--

 Summary: Deprecate StageGenerators prior to removal.
 Key: JENA-555
 URL: https://issues.apache.org/jira/browse/JENA-555
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Andy Seaborne


StageGenerators are an old way of extending SPARQL query execution.  It is 
better to extend OpExecutor (the general purpose algebra execution engine).  
OpExecutor calls the generic StageGenerator currently.

# Remove StageGenerator from documentation on extending ARQ.
# Extract the BGP execution into a library.
# OpExecutor to directly call this library unless the context option is set.
# Don't set the global context(key = ARQ.stageGenerator) with a StageGenerator.
# Mark StageGenerator \@Deprecated
# Update examples
# Check TDB and SDB, esp TDB on single graphs.

Important here is how a graph from one of those storage subsystems, when places 
in general purpose dataset with other graph types, still manages to go to the 
storage specific BGP execution. (Maybe this does not matter - if it misses it 
will fall back to using {{find()}} so always be correct.)

We may been to retain the idea of a StageGenerator to catch the single-graph 
case but at least remove as a general extension point in favour of OpExecutor.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (JENA-555) Deprecate StageGenerators prior to removal.

2013-10-04 Thread Andy Seaborne (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JENA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne reassigned JENA-555:
--

Assignee: Andy Seaborne

> Deprecate StageGenerators prior to removal.
> ---
>
> Key: JENA-555
> URL: https://issues.apache.org/jira/browse/JENA-555
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>
> StageGenerators are an old way of extending SPARQL query execution.  It is 
> better to extend OpExecutor (the general purpose algebra execution engine).  
> OpExecutor calls the generic StageGenerator currently.
> # Remove StageGenerator from documentation on extending ARQ.
> # Extract the BGP execution into a library.
> # OpExecutor to directly call this library unless the context option is set.
> # Don't set the global context(key = ARQ.stageGenerator) with a 
> StageGenerator.
> # Mark StageGenerator \@Deprecated
> # Update examples
> # Check TDB and SDB, esp TDB on single graphs.
> Important here is how a graph from one of those storage subsystems, when 
> places in general purpose dataset with other graph types, still manages to go 
> to the storage specific BGP execution. (Maybe this does not matter - if it 
> misses it will fall back to using {{find()}} so always be correct.)
> We may been to retain the idea of a StageGenerator to catch the single-graph 
> case but at least remove as a general extension point in favour of OpExecutor.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: GraphMemTest question

2013-10-04 Thread Claude Warren 
Just so we can be clear on what I am working on.  I am taking the
interfaces and creating contract tests for them.  These are a bit more
complex than standard unit tests.  For example the Graph interface contract
says that when a triple is deleted the listener is notified.  The contract
also specifies that the listener should be notified immediately after the
add but before the transaction finished.  If the transaction is rolled back
the back out commands must also be sent to the listener.

Anyway, I am creating contract tests for the interfaces and leaving the
anything not covered by the contract test in the specific implementation
classes.

I am also using the junit-contract suite for some the testing in the model
framework (https://github.com/Claudenw/junit-contracts) where I need to
include the contract tests for multiple interfaces in one suite.

I was most of the way through the model tests when I ran into a problem and
had to take a break to write the junit-contract test runner.  I am back on
track now and pushing ahead.  I should have a major checkin on the branch
in the next few days.

Claude


On Fri, Oct 4, 2013 at 2:09 PM, Andy Seaborne  wrote:

> On 04/10/13 13:03, Chris_Dollin wrote:
>
>> Andy wrote:
>>
>>  On Thursday, October 03, 2013 08:55:03 PM Claude Warren wrote:

> I find a test called testUnnecessaryMatches() that verifies that when
> the
> graph.find() method is called it does not call node_URI.matches()
>
> patterns checked are (Node_URI, ANY, ANY )
> patterns checked are (ANY, Node_URI,  ANY )
> patterns checked are (ANY, ANY, Node_URI )
>
> My question is:
>
> Is this a general restriction (i.e. all graph implementations should
> meet
> this) or specific to the memory graph?
>

 I'm pretty sure that it's specific to GraphMem and that's it's checking
 that Mem does the work itself rather than relying on GraphBase.

 [If it had been graph-implementation-agnostic I'd have put it in the

test-any-graph tests. I hope. If my memory serves.]

 Chris

>>>
>>> Chris - how much of match* (Node and Triple) was for QueryHandler ? or
>>> is specific to GraphMem?
>>>
>>
>> Oh, good point -- it's there for the QueryHandler stuff, which GraphMem
>> knew about and optimised the general case. Well, maybe it optimised,
>> there wasn't any actual testing done there.
>>
>>  If it's just for GraphMem now, one option is to move the code to a class
>>> of function in chhj.mem as "boolean matches(Node, Node)" etc and gently
>>> make Node / Triple have a smaller interface.
>>>
>>
>> If it's not used elsewjere -- which seems likely -- yes, that's a good
>> idea.
>>
>
> I may have a go at some gardening sometime (JENA-554). At a very quick
> glance, some of the GraphMem related classes may have only been used by the
> QueryHandler subsystem.
>
> Andy
>
>
>> Good catch.
>>
>> Chris
>>
>>
>


-- 
I like: Like Like - The likeliest place on the web
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: GraphMemTest question

2013-10-04 Thread Andy Seaborne 

On 04/10/13 13:03, Chris_Dollin wrote:

Andy wrote:


On Thursday, October 03, 2013 08:55:03 PM Claude Warren wrote:

I find a test called testUnnecessaryMatches() that verifies that when the
graph.find() method is called it does not call node_URI.matches()

patterns checked are (Node_URI, ANY, ANY )
patterns checked are (ANY, Node_URI,  ANY )
patterns checked are (ANY, ANY, Node_URI )

My question is:

Is this a general restriction (i.e. all graph implementations should meet
this) or specific to the memory graph?


I'm pretty sure that it's specific to GraphMem and that's it's checking
that Mem does the work itself rather than relying on GraphBase.

[If it had been graph-implementation-agnostic I'd have put it in the

   test-any-graph tests. I hope. If my memory serves.]

Chris


Chris - how much of match* (Node and Triple) was for QueryHandler ? or
is specific to GraphMem?


Oh, good point -- it's there for the QueryHandler stuff, which GraphMem
knew about and optimised the general case. Well, maybe it optimised,
there wasn't any actual testing done there.


If it's just for GraphMem now, one option is to move the code to a class
of function in chhj.mem as "boolean matches(Node, Node)" etc and gently
make Node / Triple have a smaller interface.


If it's not used elsewjere -- which seems likely -- yes, that's a good idea.


I may have a go at some gardening sometime (JENA-554). At a very quick 
glance, some of the GraphMem related classes may have only been used by 
the QueryHandler subsystem.


Andy



Good catch.

Chris

[jira] [Created] (JENA-554) See if Node.matches and triple.matches operations are needed any more.

2013-10-04 Thread Andy Seaborne (JIRA) 
Andy Seaborne created JENA-554:
--

 Summary: See if Node.matches and triple.matches operations are 
needed any more.
 Key: JENA-554
 URL: https://issues.apache.org/jira/browse/JENA-554
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Andy Seaborne
Priority: Minor


And also GraphMem may have some classes that were used by the QueryHandler 
system and no longer are used or are reachable.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: GraphMemTest question

2013-10-04 Thread Chris_Dollin 
Andy wrote:

> > On Thursday, October 03, 2013 08:55:03 PM Claude Warren wrote:
> >> I find a test called testUnnecessaryMatches() that verifies that when the
> >> graph.find() method is called it does not call node_URI.matches()
> >> 
> >> patterns checked are (Node_URI, ANY, ANY )
> >> patterns checked are (ANY, Node_URI,  ANY )
> >> patterns checked are (ANY, ANY, Node_URI )
> >> 
> >> My question is:
> >> 
> >> Is this a general restriction (i.e. all graph implementations should meet
> >> this) or specific to the memory graph?
> > 
> > I'm pretty sure that it's specific to GraphMem and that's it's checking
> > that Mem does the work itself rather than relying on GraphBase.
> > 
> > [If it had been graph-implementation-agnostic I'd have put it in the
> > 
> >   test-any-graph tests. I hope. If my memory serves.]
> > 
> > Chris
> 
> Chris - how much of match* (Node and Triple) was for QueryHandler ? or
> is specific to GraphMem?

Oh, good point -- it's there for the QueryHandler stuff, which GraphMem
knew about and optimised the general case. Well, maybe it optimised,
there wasn't any actual testing done there.

> If it's just for GraphMem now, one option is to move the code to a class
> of function in chhj.mem as "boolean matches(Node, Node)" etc and gently
> make Node / Triple have a smaller interface.

If it's not used elsewjere -- which seems likely -- yes, that's a good idea.

Good catch.

Chris

Re: GraphMemTest question

2013-10-04 Thread Andy Seaborne 

On 04/10/13 06:49, Chris_Dollin wrote:

On Thursday, October 03, 2013 08:55:03 PM Claude Warren wrote:


I find a test called testUnnecessaryMatches() that verifies that when the
graph.find() method is called it does not call node_URI.matches()

patterns checked are (Node_URI, ANY, ANY )
patterns checked are (ANY, Node_URI,  ANY )
patterns checked are (ANY, ANY, Node_URI )

My question is:

Is this a general restriction (i.e. all graph implementations should meet
this) or specific to the memory graph?


I'm pretty sure that it's specific to GraphMem and that's it's checking
that Mem does the work itself rather than relying on GraphBase.

[If it had been graph-implementation-agnostic I'd have put it in the
  test-any-graph tests. I hope. If my memory serves.]

Chris



Chris - how much of match* (Node and Triple) was for QueryHandler ? or 
is specific to GraphMem?


If it's just for GraphMem now, one option is to move the code to a class 
of function in chhj.mem as "boolean matches(Node, Node)" etc and gently 
make Node / Triple have a smaller interface.


It may save time for Claude as well.

Andy