[jira] [Commented] (JENA-612) Fuseki does not log an error when failing to open a TDB dataset
[ https://issues.apache.org/jira/browse/JENA-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259403#comment-14259403 ] Hudson commented on JENA-612: - SUCCESS: Integrated in Jena_New_Tests #169 (See [https://builds.apache.org/job/Jena_New_Tests/169/]) JENA-612 : Catch stdout and stderr : This closes #13 (andy: rev 03342b1aaf8a0b7cb33516aaf5aa24582e5ab6bd) * jena-fuseki2/fuseki * jena-fuseki/fuseki Fuseki does not log an error when failing to open a TDB dataset --- Key: JENA-612 URL: https://issues.apache.org/jira/browse/JENA-612 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 1.0.0 Reporter: Ian Dickinson Assignee: Andy Seaborne Priority: Minor Fix For: Fuseki 1.1.2, Fuseki 2.0.0 Steps to recreate: 1. Create a TDB dataset owned by user A, with no write permission for other or group. 2. Start fuseki via start-stop-daemon, per the fuseki init.d script provided in the distribution, with $FUSEKI_USER set to be a user other than A and --loc pointing to the dataset from step 1. 3. Fuseki starts, but then silently dies with no diagnostic. Analysis The --background flag in the start-stop-daemon call causes all stdout and stderr output to get silently swallowed. Fuseki does not log the failure to open the dataset to the log file, so the effect is that the daemon process terminates with no obvious explanation or diagnostic. What I would like to happen: Catch the FileException and make an entry in the Fuseki log. Stack trace for reference: com.hp.hpl.jena.tdb.base.file.FileException: Failed to open: /var/data-stores/transport/tdb/node2id.idn (mode=rw) at com.hp.hpl.jena.tdb.base.file.ChannelManager.open$(ChannelManager.java:82) at com.hp.hpl.jena.tdb.base.file.ChannelManager.openref$(ChannelManager.java:56) at com.hp.hpl.jena.tdb.base.file.ChannelManager.acquire(ChannelManager.java:45) at com.hp.hpl.jena.tdb.base.file.FileBase.init(FileBase.java:61) at com.hp.hpl.jena.tdb.base.file.FileBase.init(FileBase.java:50) at com.hp.hpl.jena.tdb.base.file.FileBase.create(FileBase.java:45) at com.hp.hpl.jena.tdb.base.file.BlockAccessBase.init(BlockAccessBase.java:46) at com.hp.hpl.jena.tdb.base.file.BlockAccessMapped.init(BlockAccessMapped.java:63) at com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.createMMapFile(BlockMgrFactory.java:90) at com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.createFile(BlockMgrFactory.java:80) at com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.create(BlockMgrFactory.java:58) at com.hp.hpl.jena.tdb.setup.Builder$BlockMgrBuilderStd.buildBlockMgr(Builder.java:196) at com.hp.hpl.jena.tdb.setup.Builder$RangeIndexBuilderStd.createBPTree(Builder.java:165) at com.hp.hpl.jena.tdb.setup.Builder$RangeIndexBuilderStd.buildRangeIndex(Builder.java:134) at com.hp.hpl.jena.tdb.setup.Builder$IndexBuilderStd.buildIndex(Builder.java:112) at com.hp.hpl.jena.tdb.setup.Builder$NodeTableBuilderStd.buildNodeTable(Builder.java:85) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd$NodeTableBuilderRecorder.buildNodeTable(DatasetBuilderStd.java:382) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.makeNodeTable(DatasetBuilderStd.java:293) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd._build(DatasetBuilderStd.java:159) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.build(DatasetBuilderStd.java:149) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.build(DatasetBuilderStd.java:64) at com.hp.hpl.jena.tdb.StoreConnection.make(StoreConnection.java:217) at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction.init(DatasetGraphTransaction.java:75) at com.hp.hpl.jena.tdb.sys.TDBMaker._create(TDBMaker.java:57) at com.hp.hpl.jena.tdb.sys.TDBMaker.createDatasetGraphTransaction(TDBMaker.java:45) at com.hp.hpl.jena.tdb.TDBFactory._createDatasetGraph(TDBFactory.java:104) at com.hp.hpl.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:73) at com.hp.hpl.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:69) at org.apache.jena.fuseki.FusekiCmd.processModulesAndArgs(FusekiCmd.java:266) at arq.cmdline.CmdArgModule.process(CmdArgModule.java:51) at arq.cmdline.CmdMain.mainMethod(CmdMain.java:100) at arq.cmdline.CmdMain.mainRun(CmdMain.java:63) at arq.cmdline.CmdMain.mainRun(CmdMain.java:50) at org.apache.jena.fuseki.FusekiCmd.main(FusekiCmd.java:141) Caused by: java.io.FileNotFoundException: /var/data-stores/transport/tdb/node2id.idn (Permission denied) at java.io.RandomAccessFile.open(Native Method) at
[jira] [Commented] (JENA-612) Fuseki does not log an error when failing to open a TDB dataset
[ https://issues.apache.org/jira/browse/JENA-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259404#comment-14259404 ] Hudson commented on JENA-612: - SUCCESS: Integrated in Jena_Commons #22 (See [https://builds.apache.org/job/Jena_Commons/22/]) JENA-612 : Catch stdout and stderr : This closes #13 (andy: rev 03342b1aaf8a0b7cb33516aaf5aa24582e5ab6bd) * jena-fuseki2/fuseki * jena-fuseki/fuseki Fuseki does not log an error when failing to open a TDB dataset --- Key: JENA-612 URL: https://issues.apache.org/jira/browse/JENA-612 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 1.0.0 Reporter: Ian Dickinson Assignee: Andy Seaborne Priority: Minor Fix For: Fuseki 1.1.2, Fuseki 2.0.0 Steps to recreate: 1. Create a TDB dataset owned by user A, with no write permission for other or group. 2. Start fuseki via start-stop-daemon, per the fuseki init.d script provided in the distribution, with $FUSEKI_USER set to be a user other than A and --loc pointing to the dataset from step 1. 3. Fuseki starts, but then silently dies with no diagnostic. Analysis The --background flag in the start-stop-daemon call causes all stdout and stderr output to get silently swallowed. Fuseki does not log the failure to open the dataset to the log file, so the effect is that the daemon process terminates with no obvious explanation or diagnostic. What I would like to happen: Catch the FileException and make an entry in the Fuseki log. Stack trace for reference: com.hp.hpl.jena.tdb.base.file.FileException: Failed to open: /var/data-stores/transport/tdb/node2id.idn (mode=rw) at com.hp.hpl.jena.tdb.base.file.ChannelManager.open$(ChannelManager.java:82) at com.hp.hpl.jena.tdb.base.file.ChannelManager.openref$(ChannelManager.java:56) at com.hp.hpl.jena.tdb.base.file.ChannelManager.acquire(ChannelManager.java:45) at com.hp.hpl.jena.tdb.base.file.FileBase.init(FileBase.java:61) at com.hp.hpl.jena.tdb.base.file.FileBase.init(FileBase.java:50) at com.hp.hpl.jena.tdb.base.file.FileBase.create(FileBase.java:45) at com.hp.hpl.jena.tdb.base.file.BlockAccessBase.init(BlockAccessBase.java:46) at com.hp.hpl.jena.tdb.base.file.BlockAccessMapped.init(BlockAccessMapped.java:63) at com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.createMMapFile(BlockMgrFactory.java:90) at com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.createFile(BlockMgrFactory.java:80) at com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.create(BlockMgrFactory.java:58) at com.hp.hpl.jena.tdb.setup.Builder$BlockMgrBuilderStd.buildBlockMgr(Builder.java:196) at com.hp.hpl.jena.tdb.setup.Builder$RangeIndexBuilderStd.createBPTree(Builder.java:165) at com.hp.hpl.jena.tdb.setup.Builder$RangeIndexBuilderStd.buildRangeIndex(Builder.java:134) at com.hp.hpl.jena.tdb.setup.Builder$IndexBuilderStd.buildIndex(Builder.java:112) at com.hp.hpl.jena.tdb.setup.Builder$NodeTableBuilderStd.buildNodeTable(Builder.java:85) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd$NodeTableBuilderRecorder.buildNodeTable(DatasetBuilderStd.java:382) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.makeNodeTable(DatasetBuilderStd.java:293) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd._build(DatasetBuilderStd.java:159) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.build(DatasetBuilderStd.java:149) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.build(DatasetBuilderStd.java:64) at com.hp.hpl.jena.tdb.StoreConnection.make(StoreConnection.java:217) at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction.init(DatasetGraphTransaction.java:75) at com.hp.hpl.jena.tdb.sys.TDBMaker._create(TDBMaker.java:57) at com.hp.hpl.jena.tdb.sys.TDBMaker.createDatasetGraphTransaction(TDBMaker.java:45) at com.hp.hpl.jena.tdb.TDBFactory._createDatasetGraph(TDBFactory.java:104) at com.hp.hpl.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:73) at com.hp.hpl.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:69) at org.apache.jena.fuseki.FusekiCmd.processModulesAndArgs(FusekiCmd.java:266) at arq.cmdline.CmdArgModule.process(CmdArgModule.java:51) at arq.cmdline.CmdMain.mainMethod(CmdMain.java:100) at arq.cmdline.CmdMain.mainRun(CmdMain.java:63) at arq.cmdline.CmdMain.mainRun(CmdMain.java:50) at org.apache.jena.fuseki.FusekiCmd.main(FusekiCmd.java:141) Caused by: java.io.FileNotFoundException: /var/data-stores/transport/tdb/node2id.idn (Permission denied) at java.io.RandomAccessFile.open(Native Method) at
[jira] [Commented] (JENA-597) IRIResolverNormal needs thread safe CacheLRU
[ https://issues.apache.org/jira/browse/JENA-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13835127#comment-13835127 ] Hudson commented on JENA-597: - ABORTED: Integrated in Jena_Development_Test #1053 (See [https://builds.apache.org/job/Jena_Development_Test/1053/]) JENA-597 Sync wrapper for the global resolver. (andy: rev 1546406) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/system/IRIResolver.java IRIResolverNormal needs thread safe CacheLRU Key: JENA-597 URL: https://issues.apache.org/jira/browse/JENA-597 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.11.0 Environment: IBM Websphere 8 JRE Reporter: Scott Patterson Assignee: Andy Seaborne Fix For: Jena 2.11.1 Attachments: IRIResolverTest.java, JENA-597-1.patch, JENA-597-2.patch The following exception may occur when more than one thread requires access to the org.apache.jena.atlas.lib.cache.CacheLRU embedded in IRIResolverNormal: Caused by: java.lang.NullPointerException at java.util.LinkedHashMap.get(LinkedHashMap.java:339) at org.apache.jena.atlas.lib.cache.CacheLRU.get(CacheLRU.java:53) at org.apache.jena.riot.system.IRIResolver$IRIResolverNormal.resolveSilent(IRIResolver.java:427) at org.apache.jena.riot.system.IRIResolver$IRIResolverNormal.init(IRIResolver.java:383) at org.apache.jena.riot.system.IRIResolver.create(IRIResolver.java:210) at org.apache.jena.riot.system.RiotLib.profile(RiotLib.java:141) at org.apache.jena.riot.system.RiotLib.profile(RiotLib.java:130) at org.apache.jena.riot.lang.LangRDFXML.init(LangRDFXML.java:104) at org.apache.jena.riot.lang.LangRDFXML.create(LangRDFXML.java:74) at org.apache.jena.riot.RiotReader.createParser(RiotReader.java:128) at org.apache.jena.riot.RDFParserRegistry$ReaderRIOTFactoryImpl$1.read(RDFParserRegistry.java:141) at org.apache.jena.riot.RDFDataMgr.process(RDFDataMgr.java:818) at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:258) at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:244) at org.apache.jena.riot.adapters.RDFReaderRIOT.read(RDFReaderRIOT.java:69) at com.ibm.team.jis.lqe.resource.RDFEntity.getModel(RDFEntity.java:361) ... 39 more This may be related to the problem reported that is suppose to be fixed by the cloned issue. It looks to be the same stack trace. I've attached a test to reproduce. Works with Oracle Oracle JRE 1.6.0.27 but not IBM jre. Keep stopping and restarting the test until the NPE happens. NPE usually happens right off the start. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-598) SPARQL Load requires correct http content-type, should fall back to file ending
[
https://issues.apache.org/jira/browse/JENA-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13835128#comment-13835128
]
Hudson commented on JENA-598:
-
ABORTED: Integrated in Jena_Development_Test #1053 (See
[https://builds.apache.org/job/Jena_Development_Test/1053/])
JENA-598 - Use URL file extension if no content type (or it's text/plain) by
using RDFDataMgr.determineLang.
And various null point situations handled more gracefully (found during
debugging). (andy: rev 1546450)
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateEngineWorker.java
* /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/ContentType.java
* /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/RDFDataMgr.java
* /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/RDFLanguages.java
* /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java
SPARQL Load requires correct http content-type, should fall back to file
ending
---
Key: JENA-598
URL: https://issues.apache.org/jira/browse/JENA-598
Project: Apache Jena
Issue Type: Bug
Components: Jena
Affects Versions: Fuseki 1.0.0
Reporter: Håvard Ottestad
Assignee: Andy Seaborne
Priority: Trivial
Fix For: Fuseki 1.0.1, Jena 2.11.1
Original Estimate: 6h
Remaining Estimate: 6h
A SPARQL Update query with a LOAD command requires a correct HTTP
content-type (mime-type) to be returned with the GET request when downloading
the file.
Should have 2 failovers:
1. Attempt to use file ending. .ttl == TTL .xml == RDF/XML and so on
2. Attempt to read the file with a different language (eg. if TTL fails, try
RDF/XML)
The code for this seems to be here:
https://svn.apache.org/repos/asf/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateEngineWorker.java
@Override
public void visit(UpdateLoad update)
{
String source = update.getSource() ;
Node dest = update.getDest() ;
try {
// Read into temporary storage to protect against parse errors.
TypedInputStream s = RDFDataMgr.open(source) ;
Lang lang = RDFLanguages.contentTypeToLang(s.getContentType()) ;
//--- THIS IS WHERE THE BUG IS ---//
if ( RDFLanguages.isTriples(lang) ) {
// Triples
Graph g = GraphFactory.createGraphMem() ;
StreamRDF stream = StreamRDFLib.graph(g) ;
RDFDataMgr.parse(stream, s, source) ;
Graph g2 = graph(graphStore, dest) ;
GraphUtil.addInto(g2, g) ;
} else {
// Quads
if ( dest != null )
throw new UpdateException(Attempt to load quads into a
graph) ;
DatasetGraph dsg = DatasetGraphFactory.createMem() ;
StreamRDF stream = StreamRDFLib.dataset(dsg) ;
RDFDataMgr.parse(stream, s, source) ;
IteratorQuad iter = dsg.find() ;
for ( ; iter.hasNext() ; )
{
Quad q = iter.next() ;
graphStore.add(q) ;
}
}
} catch (RuntimeException ex)
{
if ( ! update.getSilent() )
{
if ( ex instanceof UpdateException )
throw (UpdateException)ex ;
throw new UpdateException(Failed to LOAD '+source+', ex) ;
}
}
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (JENA-596) Schemagen does not work with Maven 3.1.x
[ https://issues.apache.org/jira/browse/JENA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832310#comment-13832310 ] Hudson commented on JENA-596: - ABORTED: Integrated in Jena_Development_Test #1051 (See [https://builds.apache.org/job/Jena_Development_Test/1051/]) Patch for JENA-596 contributed by Shane St Clair (ijd: rev 1545389) * /jena/trunk/jena-maven-tools/pom.xml * /jena/trunk/jena-maven-tools/src/main/java/org/openjena/tools/schemagen/SchemagenMojo.java * /jena/trunk/jena-maven-tools/src/main/java/org/openjena/tools/schemagen/SchemagenOption.java * /jena/trunk/jena-maven-tools/src/main/java/org/openjena/tools/schemagen/SchemagenOptions.java * /jena/trunk/jena-maven-tools/src/main/java/org/openjena/tools/schemagen/SchemagenOptionsConfigurationException.java * /jena/trunk/jena-maven-tools/src/main/java/org/openjena/tools/schemagen/Source.java * /jena/trunk/jena-maven-tools/src/test/java/org/openjena/tools/schemagen/SchemagenOptionsTest.java * /jena/trunk/jena-maven-tools/src/test/java/org/openjena/tools/schemagen/SourceParameterTest.java * /jena/trunk/jena-maven-tools/src/test/java/org/openjena/tools/schemagen/SourceTest.java Schemagen does not work with Maven 3.1.x Key: JENA-596 URL: https://issues.apache.org/jira/browse/JENA-596 Project: Apache Jena Issue Type: Bug Reporter: Ian Dickinson Assignee: Ian Dickinson Attachments: jena-maven-tools.patch Maven 3.1.x has changed the way that POM parameters are passed to plugin code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-595) Improve filter placement optimization
[ https://issues.apache.org/jira/browse/JENA-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13830949#comment-13830949 ] Hudson commented on JENA-595: - SUCCESS: Integrated in Jena_Development_Test #1049 (See [https://builds.apache.org/job/Jena_Development_Test/1049/]) Fixes issue with JENA-595 (claude: rev 1544967) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformFilterPlacement.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilterPlacement.java Improve filter placement optimization - Key: JENA-595 URL: https://issues.apache.org/jira/browse/JENA-595 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Andy Seaborne Assignee: Andy Seaborne Attachments: FilterPlacementError.java, JENA-595-FilterPlacement.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-595) Improve filter placement optimization
[ https://issues.apache.org/jira/browse/JENA-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13830992#comment-13830992 ] Hudson commented on JENA-595: - ABORTED: Integrated in Jena_Development_Test #1050 (See [https://builds.apache.org/job/Jena_Development_Test/1050/]) More general fix for JENA-595. (andy: rev 1545008) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformFilterPlacement.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilterPlacement.java Improve filter placement optimization - Key: JENA-595 URL: https://issues.apache.org/jira/browse/JENA-595 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Andy Seaborne Assignee: Andy Seaborne Attachments: FilterPlacementError.java, JENA-595-FilterPlacement.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-595) Improve filter placement optimization
[ https://issues.apache.org/jira/browse/JENA-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13830134#comment-13830134 ] Hudson commented on JENA-595: - SUCCESS: Integrated in Jena_Development_Test #1046 (See [https://builds.apache.org/job/Jena_Development_Test/1046/]) JENA-595 New filter placement code. (andy: rev 1544468) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/OpVars.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/Optimize.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformFilterPlacement.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformFilterPlacement_Old.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/TS_Algebra.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/TestOpVar.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/TestOpVars.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilterPlacement.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilters.java Improve filter placement optimization - Key: JENA-595 URL: https://issues.apache.org/jira/browse/JENA-595 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Andy Seaborne Assignee: Andy Seaborne Attachments: JENA-595-FilterPlacement.patch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-589) Add read(Reader,...) to the general ReaderRIOT interface.
[ https://issues.apache.org/jira/browse/JENA-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13824425#comment-13824425 ] Hudson commented on JENA-589: - SUCCESS: Integrated in Jena_Development_Test #1042 (See [https://builds.apache.org/job/Jena_Development_Test/1042/]) JENA-589 : Add java.io.Reader as first-class source (caveats about character sets). (andy: rev 1542256) * /jena/trunk/jena-arq/src-examples/arq/examples/riot/ExRIOT_5.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/SSE.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/RDFDataMgr.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/RDFParserRegistry.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/ReaderRIOT.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/RiotReader.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/LangRDFXML.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/TestJenaReaderRIOT.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/writer/TestRDFJSON.java Add read(Reader,...) to the general ReaderRIOT interface. - Key: JENA-589 URL: https://issues.apache.org/jira/browse/JENA-589 Project: Apache Jena Issue Type: Improvement Components: RIOT Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.11.1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-588) TDBLoader does not throw exception when disk full
[ https://issues.apache.org/jira/browse/JENA-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13824424#comment-13824424 ] Hudson commented on JENA-588: - SUCCESS: Integrated in Jena_Development_Test #1042 (See [https://builds.apache.org/job/Jena_Development_Test/1042/]) JENA-588 : Don't catch and surpress exception. (andy: rev 1542241) * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/store/bulkloader/LoaderNodeTupleTable.java TDBLoader does not throw exception when disk full - Key: JENA-588 URL: https://issues.apache.org/jira/browse/JENA-588 Project: Apache Jena Issue Type: Bug Components: TDB Affects Versions: Jena 2.10.0 Reporter: Brian Caruso Assignee: Andy Seaborne Attachments: jena.diskFull.patch When using tdbload a full disk does not cause the load to throw an exception and exit. The process displays logging messages about the disk and then continues to attempt to save the next triple. To reproduce fill up a temporary file system, then load a large NT file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-589) Add read(Reader,...) to the general ReaderRIOT interface.
[ https://issues.apache.org/jira/browse/JENA-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823809#comment-13823809 ] Hudson commented on JENA-589: - SUCCESS: Integrated in Jena_Development_Test_ARM #25 (See [https://builds.apache.org/job/Jena_Development_Test_ARM/25/]) JENA-589 : Add java.io.Reader as first-class source (caveats about character sets). (andy: rev 1542256) * /jena/trunk/jena-arq/src-examples/arq/examples/riot/ExRIOT_5.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/SSE.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/RDFDataMgr.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/RDFParserRegistry.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/ReaderRIOT.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/RiotReader.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/LangRDFXML.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/TestJenaReaderRIOT.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/writer/TestRDFJSON.java Add read(Reader,...) to the general ReaderRIOT interface. - Key: JENA-589 URL: https://issues.apache.org/jira/browse/JENA-589 Project: Apache Jena Issue Type: Improvement Components: RIOT Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.11.1 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-588) TDBLoader does not throw exception when disk full
[ https://issues.apache.org/jira/browse/JENA-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823808#comment-13823808 ] Hudson commented on JENA-588: - SUCCESS: Integrated in Jena_Development_Test_ARM #25 (See [https://builds.apache.org/job/Jena_Development_Test_ARM/25/]) JENA-588 : Don't catch and surpress exception. (andy: rev 1542241) * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/store/bulkloader/LoaderNodeTupleTable.java TDBLoader does not throw exception when disk full - Key: JENA-588 URL: https://issues.apache.org/jira/browse/JENA-588 Project: Apache Jena Issue Type: Bug Components: TDB Affects Versions: Jena 2.10.0 Reporter: Brian Caruso Assignee: Andy Seaborne Attachments: jena.diskFull.patch When using tdbload a full disk does not cause the load to throw an exception and exit. The process displays logging messages about the disk and then continues to attempt to save the next triple. To reproduce fill up a temporary file system, then load a large NT file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-587) SELECT DISTINCT returns duplicate results
[ https://issues.apache.org/jira/browse/JENA-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820420#comment-13820420 ] Hudson commented on JENA-587: - ABORTED: Integrated in Jena_Development_Test #1039 (See [https://builds.apache.org/job/Jena_Development_Test/1039/]) Couple more unit tests for JENA-587 (rvesse: rev 1541149) * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestOptimizer.java Re-enable TransformDistinctToReduced making it much stricter about the kinds of queries it will optimize. Expands the unit tests to cover various scenarios identified in the associated bug (JENA-587) (rvesse: rev 1541139) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/Optimize.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformDistinctToReduced.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestOptimizer.java Make TransformDistinctToReduced off by default until it can be refactored to only apply when safe, also disables affected tests for now (JENA-587) (rvesse: rev 1541019) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/Optimize.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestOptimizer.java SELECT DISTINCT returns duplicate results - Key: JENA-587 URL: https://issues.apache.org/jira/browse/JENA-587 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.11.0 Reporter: Veyriere Assignee: Rob Vesse Attachments: D.ttl, Q.rq, bug Jena2.11.0.zip, jena-587.zip SELECT DISTINCT returns duplicate results. Attaching a small quads dump and the query to reproduce with TDB Reproduced with Jena 2.11.0 and Jena 2.10.1 (was working with 2.7.4) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-585) model.read(url) to be more general in syntax choice.
[
https://issues.apache.org/jira/browse/JENA-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13818210#comment-13818210
]
Hudson commented on JENA-585:
-
SUCCESS: Integrated in Jena_Development_Test #1037 (See
[https://builds.apache.org/job/Jena_Development_Test/1037/])
JENA-585 : Add a reader that is as web-friendly as possible. (andy: rev 1540337)
*
/jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/adapters/AdapterFileManager.java
*
/jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/adapters/RDFReaderRIOT.java
*
/jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/adapters/RDFReaderRIOT_Web.java
*
/jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/system/IO_JenaReaders.java
*
/jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/system/TestIO_JenaReaders.java
*
/jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/RDFReaderFImpl.java
model.read(url) to be more general in syntax choice.
Key: JENA-585
URL: https://issues.apache.org/jira/browse/JENA-585
Project: Apache Jena
Issue Type: Improvement
Affects Versions: Jena 2.10.1
Reporter: Andy Seaborne
Assignee: Andy Seaborne
Priority: Minor
Currently, {{model.read(url)}} will choose RDF/XML too readily.
The decision should be: content-type (if not text/plain), guess from URl file
extension, and only as a last resort RDF/XML (best for compatibility). Other
operations already exist for the app to name the syntax directly.
The presenting problem is a file like http://host/data.ttl just dumped on a
server - it probably get served as text/plain. RDFDataMgr.read(url) will
work. This JIRA is extending that to model.read(url) where there is always a
default syntax. Normally, if the syntax is given, it is to override the
implicit one but in this case we want it to be a soft default, only used if
there is no other sensible choice.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (JENA-581) Parsing using StreamRDF to java Collection
[ https://issues.apache.org/jira/browse/JENA-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812041#comment-13812041 ] Hudson commented on JENA-581: - ABORTED: Integrated in Jena_Development_Test #1032 (See [https://builds.apache.org/job/Jena_Development_Test/1032/]) JENA-581 : Collector pattern for parsing. (andy: rev 1538185) * /jena/trunk/jena-arq/src-examples/arq/examples/riot/ExRIOT_7.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/CollectorStreamBase.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/CollectorStreamQuads.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/CollectorStreamTriples.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/CollectorStreamTuples.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/lang/TS_Lang.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/lang/TestCollectorStream.java Parsing using StreamRDF to java Collection -- Key: JENA-581 URL: https://issues.apache.org/jira/browse/JENA-581 Project: Apache Jena Issue Type: Improvement Components: RIOT Reporter: Andy Seaborne Assignee: Andy Seaborne Fix For: Jena 2.11.1 Attachments: collectorstreams.patch This records: http://mail-archives.apache.org/mod_mbox/jena-dev/201311.mbox/%3CA299416A57087D4FA73D95315E7703312866E38C%40UDSMBX01.uds.nuigalway.ie%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-577) TDB detects attempt to reassign a variable.
[
https://issues.apache.org/jira/browse/JENA-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13808000#comment-13808000
]
Hudson commented on JENA-577:
-
SUCCESS: Integrated in Jena_Development_Test #1029 (See
[https://builds.apache.org/job/Jena_Development_Test/1029/])
JENA-577 : Rewrite merging bindings when an OpProject is in the middel of an
execution (sub-SELECT). (andy: rev 1536710)
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/binding/BindingProject.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/binding/BindingProjectBase.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/binding/BindingProjectNamed.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/binding/BindingUtils.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/iterator/QueryIterProject2.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/iterator/QueryIterProjectMerge.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/main/OpExecutor.java
TDB detects attempt to reassign a variable.
---
Key: JENA-577
URL: https://issues.apache.org/jira/browse/JENA-577
Project: Apache Jena
Issue Type: Bug
Components: ARQ, TDB
Affects Versions: Jena 2.11.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne
Attachments: DevMain.java
With TDB, but not with a general in-memory dataset, a query of the form:
{noformat}
PREFIX : http://example/
SELECT *
WHERE
{ ?x :p 123
{ SELECT ?x
WHERE
{ ?x :p ?o }
}
}
{noformat}
(key feature: projection from the subsquery)
causes
{noformat}
20:24:32 ERROR QueryIteratorCloseable:: QueryFatalException
com.hp.hpl.jena.sparql.ARQInternalErrorException: Attempt to reassign '?x'
from 'http://example/x' to 'http://example/x'
at
com.hp.hpl.jena.sparql.engine.binding.BindingHashMap.checkAdd(BindingHashMap.java:111)
at
com.hp.hpl.jena.sparql.engine.binding.BindingHashMap.add(BindingHashMap.java:92)
at
com.hp.hpl.jena.sparql.engine.binding.BindingFactory.materialize(BindingFactory.java:60)
at
com.hp.hpl.jena.tdb.solver.QueryEngineTDB$QueryIteratorMaterializeBinding.moveToNextBinding(QueryEngineTDB.java:132)
at
com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.nextBinding(QueryIteratorBase.java:154)
{noformat}
Looking at the optimized algebra, TDB is correct.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (JENA-540) RDFWriterF does not have a mechanism to unregister an RDFWriter.
[ https://issues.apache.org/jira/browse/JENA-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806670#comment-13806670 ] Hudson commented on JENA-540: - FAILURE: Integrated in Jena_Development_Test #1025 (See [https://builds.apache.org/job/Jena_Development_Test/1025/]) JENA-540 Added resetRDFWriterF() and removeWriter() Updated documentation (claude: rev 1536294) * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/RDFWriterF.java * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/ModelCom.java * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/RDFWriterFImpl.java * /jena/trunk/jena-core/src/test/java/com/hp/hpl/jena/rdf/model/test/TestRDFWriterMap.java * /jena/trunk/jena-security/src/main/java/org/apache/jena/security/model/impl/SecuredModelImpl.java RDFWriterF does not have a mechanism to unregister an RDFWriter. Key: JENA-540 URL: https://issues.apache.org/jira/browse/JENA-540 Project: Apache Jena Issue Type: New Feature Components: Jena Affects Versions: Jena 2.11.0 Reporter: Claude Warren Assignee: Claude Warren Once a writer is registered with RDFWriterF.setWriterClassName() there is no mechanism to unregister it. I suggest allowing a null for the second parameter to remove a registered writer and to throw an exception when the default writer is removed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-539) RDFReaderF does not have a method to remove a registered reader
[ https://issues.apache.org/jira/browse/JENA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806883#comment-13806883 ] Hudson commented on JENA-539: - SUCCESS: Integrated in Jena_Development_Test #1027 (See [https://builds.apache.org/job/Jena_Development_Test/1027/]) JENA-539 Added code to remove RDFReaders from RDFReaderF added documentation fixed some documentation in RDFWriterF fixed a null ponter error in RDFWriterF (claude: rev 1536382) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/adapters/RDFReaderFactoryRIOT.java * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/RDFReaderF.java * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/RDFWriterF.java * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/ModelCom.java * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/RDFReaderFImpl.java * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/RDFWriterFImpl.java * /jena/trunk/jena-security/src/main/java/org/apache/jena/security/model/impl/SecuredModelImpl.java RDFReaderF does not have a method to remove a registered reader --- Key: JENA-539 URL: https://issues.apache.org/jira/browse/JENA-539 Project: Apache Jena Issue Type: New Feature Components: Jena Affects Versions: Jena 2.11.0 Reporter: Claude Warren Assignee: Claude Warren RDFReaderF has a mechanism to set a reader but does not have a mechanism to remove a reader once set. Suggest accepting null as the second argument in setReaderClassName() to indicate that the reader type should be removed from the list. In addition, removal of the default reader should throw an exception. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-543) Seq created from resource in another model results in Seq from the wrong model.
[ https://issues.apache.org/jira/browse/JENA-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806359#comment-13806359 ] Hudson commented on JENA-543: - SUCCESS: Integrated in Jena_Development_Test #1023 (See [https://builds.apache.org/job/Jena_Development_Test/1023/]) Fix for JENA-543 added inModel() to getSeq() (claude: rev 1536150) * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/ModelCom.java Seq created from resource in another model results in Seq from the wrong model. --- Key: JENA-543 URL: https://issues.apache.org/jira/browse/JENA-543 Project: Apache Jena Issue Type: Bug Components: Jena Affects Versions: Jena 2.11.0 Reporter: Claude Warren Assignee: Claude Warren Attachments: SeqTest.java, SeqTest.java Create model 1. Create a resource in model 1 Create model 2 call Seq s = model2.getSeq( resource ) s.getModel() == model1 is true s.getModel() == model2 is false s.getModel() should return model2 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-544) Bag created from a resource in another model results in a Bag in the wrong model
[ https://issues.apache.org/jira/browse/JENA-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806361#comment-13806361 ] Hudson commented on JENA-544: - SUCCESS: Integrated in Jena_Development_Test #1024 (See [https://builds.apache.org/job/Jena_Development_Test/1024/]) Fix for JENA-544 added inModel() to getBag() (claude: rev 1536154) * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/ModelCom.java Bag created from a resource in another model results in a Bag in the wrong model Key: JENA-544 URL: https://issues.apache.org/jira/browse/JENA-544 Project: Apache Jena Issue Type: Bug Components: Jena Affects Versions: Jena 2.11.0 Reporter: Claude Warren Assignee: Claude Warren Attachments: BagTest.java Create model 1. Create a resource in model 1 Create model 2 call Bag s = model2.getBag( resource ) s.getModel() == model1 is true s.getModel() == model2 is false s.getModel() should return model2 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-574) Assembler description files given to command line utilities misform the base URI
[ https://issues.apache.org/jira/browse/JENA-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806150#comment-13806150 ] Hudson commented on JENA-574: - SUCCESS: Integrated in Jena_Development_Test #1019 (See [https://builds.apache.org/job/Jena_Development_Test/1019/]) JENA-574 (andy: rev 1536016) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/adapters/AdapterFileManager.java Assembler description files given to command line utilities misform the base URI Key: JENA-574 URL: https://issues.apache.org/jira/browse/JENA-574 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor See http://mail-archives.apache.org/mod_mbox/jena-users/201310.mbox/%3C5267F88E.3060300%40gmail.com%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-571) GraphTDB fails to implements .close() but fails to pass this up to GraphBase.
[ https://issues.apache.org/jira/browse/JENA-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805320#comment-13805320 ] Hudson commented on JENA-571: - SUCCESS: Integrated in Jena_Development_Test #1015 (See [https://builds.apache.org/job/Jena_Development_Test/1015/]) JENA-571 (andy: rev 1535724) * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/graph/Graph.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/store/GraphTDB.java GraphTDB fails to implements .close() but fails to pass this up to GraphBase. - Key: JENA-571 URL: https://issues.apache.org/jira/browse/JENA-571 Project: Apache Jena Issue Type: Bug Components: TDB Affects Versions: TDB 1.0.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.11.1 from: http://mail-archives.apache.org/mod_mbox/jena-dev/201310.mbox/%3CCALvhUEWRutgUOMqKpFaqK38Lr5ZKhUpAhoYVDEvMarEKaWtPKQ%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-572) ARQ should provide a convenient way to set the User-Agent for HTTP requests
[ https://issues.apache.org/jira/browse/JENA-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805475#comment-13805475 ] Hudson commented on JENA-572: - SUCCESS: Integrated in Jena_Development_Test #1016 (See [https://builds.apache.org/job/Jena_Development_Test/1016/]) Add support for configuring User-Agent header via HttpOp, set a sensible default value for general usage (JENA-572) (rvesse: rev 1535776) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java ARQ should provide a convenient way to set the User-Agent for HTTP requests --- Key: JENA-572 URL: https://issues.apache.org/jira/browse/JENA-572 Project: Apache Jena Issue Type: Improvement Components: ARQ Affects Versions: Jena 2.11.0 Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.11.1 As discussed over at https://github.com/pyvandenbussche/sparqles/issues/9 as of 2.11.0 ARQ provides centralised HTTP operations which allows for setting global HTTP configuration. One thing that it would be particularly useful to set is the User-Agent header so that people using ARQ to write RDF/SPARQL robots can assign an appropriate User-Agent to their requests. Currently we do not change the header at all so sites will see the generic Apache HttpClient User-Agent header. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-567) Improve Fuseki/TDB transaction memory usage
[ https://issues.apache.org/jira/browse/JENA-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13804936#comment-13804936 ] Hudson commented on JENA-567: - SUCCESS: Integrated in Jena_Development_Test #1014 (See [https://builds.apache.org/job/Jena_Development_Test/1014/]) JENA-567 Add option to TDB for specifying where the temporary write blocks for the BlockMgrJournal come from. Also added a memory mapped ByteBuffer allocator to work with the new BlockMgrJournal functionality. (sallen: rev 1535599) * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/TDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/base/block/Block.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/base/file/BufferAllocator.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/base/file/BufferAllocatorDirect.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/base/file/BufferAllocatorMapped.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/base/file/BufferAllocatorMem.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/transaction/BlockMgrJournal.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/transaction/Journal.java Improve Fuseki/TDB transaction memory usage --- Key: JENA-567 URL: https://issues.apache.org/jira/browse/JENA-567 Project: Apache Jena Issue Type: Improvement Components: TDB Reporter: Stephen Allen Assignee: Stephen Allen TDB has to buffer in memory all of the modified blocks for a transaction before committing it. This causes out of memory exceptions when attempting to add a large number of statements in a single transaction. An easy way to fix this would be to copy the write block contents into a memory mapped file instead of heap memory ^†^. We can provide three user specified options for controlling the location of the temporary blocks: # JVM heap (default, and what we currently use) # Direct memory (process heap, but not in the JVM) # Memory mapped temporary file See this [Jena thread| http://markmail.org/thread/ckeevvhl2luevixw] for some additional discussion. ^†^ _The harder way would involve writing the old blocks to the journal, then writing the new blocks directly to the indexes, with a tombstone pointing to the old block in the journal so that readers could still retrieve the old version. This however would seem to require a substantial refactor, as well as a change to the on-disk database format._ -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-565) Mishandling dates before the year 999
[ https://issues.apache.org/jira/browse/JENA-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802770#comment-13802770 ] Hudson commented on JENA-565: - SUCCESS: Integrated in Jena_Development_Test #1013 (See [https://builds.apache.org/job/Jena_Development_Test/1013/]) JENA-565 (andy: rev 1534973) * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/datatypes/xsd/XSDDateTime.java * /jena/trunk/jena-core/src/test/java/com/hp/hpl/jena/graph/test/TestTypedLiterals.java Mishandling dates before the year 999 - Key: JENA-565 URL: https://issues.apache.org/jira/browse/JENA-565 Project: Apache Jena Issue Type: Bug Components: Datatypes Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Fix For: Jena 2.11.1 http://mail-archives.apache.org/mod_mbox/jena-users/201310.mbox/%3C3184913994B8A945952A774DECB84FE770972999%40NDHEP50003.na.corp.mckesson.com%3E XSDDateTime.toString does not pad numbers less than 1000 with zeros but this is needed for xsd:dateTime. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-564) JSON parse errors blocks later use of JSON parser
[ https://issues.apache.org/jira/browse/JENA-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794181#comment-13794181 ] Hudson commented on JENA-564: - SUCCESS: Integrated in Jena_Development_Test #1000 (See [https://builds.apache.org/job/Jena_Development_Test/1000/]) JENA-564 (andy: rev 1531932) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/io/CharStreamBuffered.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/io/PeekReader.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/json/io/parser/JSONP.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/json/io/parser/JSONParserBase.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/json/io/parser/ParserBase.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/json/io/parser/TokenizerJSON.java JSON parse errors blocks later use of JSON parser - Key: JENA-564 URL: https://issues.apache.org/jira/browse/JENA-564 Project: Apache Jena Issue Type: Bug Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.11.1 See http://mail-archives.apache.org/mod_mbox/jena-users/201310.mbox/%3C525B3406.7000302%40knublauch.com%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-559) line number for syntax error lost
[ https://issues.apache.org/jira/browse/JENA-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13787785#comment-13787785 ] Hudson commented on JENA-559: - ABORTED: Integrated in Jena_Development_Test #986 (See [https://builds.apache.org/job/Jena_Development_Test/986/]) JENA-559 : Line and column number for RDF/XML parsing. (andy: rev 1529691) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/LangRDFXML.java line number for syntax error lost - Key: JENA-559 URL: https://issues.apache.org/jira/browse/JENA-559 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.11.0 Environment: % uname -a Linux oem-laptop 3.8.0-32-generic #47-Ubuntu SMP Tue Oct 1 22:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux % java -version java version 1.7.0_40 Java(TM) SE Runtime Environment (build 1.7.0_40-b43) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode) Reporter: Jean-Marc Vanel Assignee: Andy Seaborne Fix For: Jena 2.11.1 Attachments: JENA2.11.1-SNAPSHOT.patch in the Exception created for a RDF syntax error , the line number is lost Patch attached - not optimal coding but does the job. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-558) Requests to the general SPARQL processor leave a stacktrace in the log file
[ https://issues.apache.org/jira/browse/JENA-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13787187#comment-13787187 ] Hudson commented on JENA-558: - FAILURE: Integrated in Jena_Development_Test #983 (See [https://builds.apache.org/job/Jena_Development_Test/983/]) JENA-558 : Configure for the general SPARQL processor. (andy: rev 1529436) * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/CounterSet.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/DatasetRef.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/FusekiConfig.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_ServletBase.java Requests to the general SPARQL processor leave a stacktrace in the log file --- Key: JENA-558 URL: https://issues.apache.org/jira/browse/JENA-558 Project: Apache Jena Issue Type: Bug Components: Fuseki Affects Versions: Fuseki 1.0.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Fix For: Fuseki 1.0.1 Requests to the general SPARQL processor leave a stacktrace in the log file. The actual observed effect is due to no counters being available but the general issue is that there isn't a proper DatasetRef/ServiceRef setup when there is no defined dataset. -- 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.
[
https://issues.apache.org/jira/browse/JENA-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 http://mytest;
insert data { graph http://mytest { _:b0 http://test test }};
WITH http://mytest
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 http://test 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-552) All variables unbound if SERVICE SILENT fails
[
https://issues.apache.org/jira/browse/JENA-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13781749#comment-13781749
]
Hudson commented on JENA-552:
-
SUCCESS: Integrated in Jena_Development_Test #974 (See
[https://builds.apache.org/job/Jena_Development_Test/974/])
JENA-552 : Return the given binding in the case of SERVICE SILENT + failure.
(andy: rev 1527515)
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/main/iterator/QueryIterService.java
All variables unbound if SERVICE SILENT fails
-
Key: JENA-552
URL: https://issues.apache.org/jira/browse/JENA-552
Project: Apache Jena
Issue Type: Bug
Components: ARQ, Fuseki, Jena
Affects Versions: Fuseki 1.0.0
Reporter: Michael Brunnbauer
Priority: Minor
I think ?ds and ?ep should be bound in the second result row:
INSERT DATA {
_:b0 http://rdfs.org/ns/void#sparqlEndpoint http://nonexistent.
_:b1 http://rdfs.org/ns/void#sparqlEndpoint
http://linkeddata.uriburner.com/sparql.
}
select ?ds ?ep ?s where {
?ds http://rdfs.org/ns/void#sparqlEndpoint ?ep.
SERVICE SILENT ?ep {
select ?s where { ?s ?p ?o } limit 1
}
}
--
| ds | ep | s|
==
| _:b0 | http://linkeddata.uriburner.com/sparql | _:b1 |
| | | |
--
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (JENA-548) Add file extension .owl as implying RDF/XML.
[ https://issues.apache.org/jira/browse/JENA-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1315#comment-1315 ] Hudson commented on JENA-548: - SUCCESS: Integrated in Jena_Development_Test #965 (See [https://builds.apache.org/job/Jena_Development_Test/965/]) JENA-548 (andy: rev 1526218) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/RDFLanguages.java Add file extension .owl as implying RDF/XML. Key: JENA-548 URL: https://issues.apache.org/jira/browse/JENA-548 Project: Apache Jena Issue Type: Bug Components: RIOT Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor See discussion and data: http://mail-archives.apache.org/mod_mbox/jena-users/201309.mbox/%3C523F1AB3.9010705%40apache.org%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-535) Algebra.toQuadForm() does not transform Expressions in Optional clauses
[
https://issues.apache.org/jira/browse/JENA-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13773060#comment-13773060
]
Hudson commented on JENA-535:
-
SUCCESS: Integrated in Jena_Development_Test #957 (See
[https://builds.apache.org/job/Jena_Development_Test/957/])
JENA-535
Process the expression in a LeftJoin condition. (andy: rev 1525025)
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/BeforeAfterVisitor.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/OpVisitorByType.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/OpVisitorByTypeBase.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/OpWalker.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/Transformer.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/op/OpFilter.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/op/OpProcedure.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/TestTransformQuads.java
Algebra.toQuadForm() does not transform Expressions in Optional clauses
---
Key: JENA-535
URL: https://issues.apache.org/jira/browse/JENA-535
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 2.11.0
Reporter: Tracy Hartford
Assignee: Andy Seaborne
Our internal testing has flagged up a failure in 2.11.0 in
Algebra.toQuadForm() when applied to expressions within an OPTIONAL clause.
The query in question is as follows:
{noformat}
SELECT *
WHERE
{ ?s ?p ?o
OPTIONAL
{
FILTER NOT EXISTS {?s ?p ?o }
}
}
{noformat}
The algebra before calling Algebra.toQuadForm() is as follows:
{noformat}
(leftjoin
(bgp (triple ?s ?p ?o))
(table unit)
(notexists (bgp (triple ?s ?p ?o
{noformat}
The expected algebra is as follows:
{noformat}
(leftjoin
(quadpattern (quad urn:x-arq:DefaultGraphNode ?s ?p ?o))
(table unit)
(notexists (quadpattern (quad urn:x-arq:DefaultGraphNode ?s ?p ?o
{noformat}
The resulting algebra is as follows:
{noformat}
(leftjoin
(quadpattern (quad urn:x-arq:DefaultGraphNode ?s ?p ?o))
(table unit)
(notexists (bgp (triple ?s ?p ?o
{noformat}
It appears that the Transform Walkers visit the left and right Ops of the
OpLeftJoin but not the ExprList that contains the E_NotExists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-532) SecuredFunction leaves stack elements behind
[ https://issues.apache.org/jira/browse/JENA-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13762415#comment-13762415 ] Hudson commented on JENA-532: - ABORTED: Integrated in Jena_Development_Test #933 (See [https://builds.apache.org/job/Jena_Development_Test/933/]) Fix for JENA-532 Added code to convert internal variables to arguments to keep the stack in sync. (claude: rev 1521302) * /jena/trunk/jena-security/src/main/java/org/apache/jena/security/query/rewriter/SecuredFunction.java SecuredFunction leaves stack elements behind Key: JENA-532 URL: https://issues.apache.org/jira/browse/JENA-532 Project: Apache Jena Issue Type: Bug Components: Security Reporter: Claude Warren Assignee: Claude Warren When running test cases the SecuredFunction leaves items on the argument stack as indicated in the log by 09:19:03 WARN ExprTransformer$ApplyExprTransformVisitor :: Stack is not aligned -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-503) Implement redirect for Fuseki once triples have been uploaded
[ https://issues.apache.org/jira/browse/JENA-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13760124#comment-13760124 ] Hudson commented on JENA-503: - SUCCESS: Integrated in Jena_Development_Test #905 (See [https://builds.apache.org/job/Jena_Development_Test/905/]) JENA-503 (andy: rev 1520533) * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Upload.java Implement redirect for Fuseki once triples have been uploaded - Key: JENA-503 URL: https://issues.apache.org/jira/browse/JENA-503 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Lewis John McGibbney Priority: Minor Fix For: Fuseki 1.0.0 Attachments: JENA-503.patch When users use the sparql.tpl form [0], they are presented with an html page which provides some simple output specifying success, with number of triples (in the case where the file(s) upload was successful) or else an HTTP status code with a brief error message (in the case where it was not successful). Regardless of the case, it would be nice to set up a redirect (say after 5 or 10 seconds) to get them back to sparql.tpl with the previously selected dataset. Additionally, it would be nice to allow backwards navigation to other forms from this form as it would save folks having to hit http://localhost:3030 every time they wish to navigate Fuseki. I don't have a patch yet, this was something which just crept in to my head right now. [0] http://svn.apache.org/repos/asf/jena/trunk/jena-fuseki/pages/sparql.tpl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-527) The jena-jdbc test suite does not reliably run on Java6
[ https://issues.apache.org/jira/browse/JENA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756226#comment-13756226 ] Hudson commented on JENA-527: - SUCCESS: Integrated in Jena_JDBC_Test #22 (See [https://builds.apache.org/job/Jena_JDBC_Test/22/]) Apply patch from JENA-527 to mitigate test hang issues for JDBC (rvesse: rev 1519506) * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/TS_JdbcDriverRemote.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/AbstractRemoteEndpointResultSetTests.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/TestRemoteEndpointResults.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/TestRemoteEndpointResultsWithAuth.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/TestRemoteEndpointResultsWithGraphUris.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/TestRemoteEndpointResultsWithResultSetTypes.java The jena-jdbc test suite does not reliably run on Java6 --- Key: JENA-527 URL: https://issues.apache.org/jira/browse/JENA-527 Project: Apache Jena Issue Type: Bug Components: JDBC Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Attachments: jdbc-testing-v1.patch The test suite does not run reliably on java6. It seems that socket resources in the kernel are being allocated and then need a timeout before the kernel has resources again. But the test suite runs to fast and will lock up waiting. Sometimes sockets in state ESTABLISHED are left around. This also leads to lock-up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-527) The jena-jdbc test suite does not reliably run on Java6
[ https://issues.apache.org/jira/browse/JENA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756229#comment-13756229 ] Hudson commented on JENA-527: - SUCCESS: Integrated in Jena_Development_Test #896 (See [https://builds.apache.org/job/Jena_Development_Test/896/]) Make ResultSetPeeking implementation Closeable (relates to JENA-527) (rvesse: rev 1519507) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/ResultSetPeeking.java Apply patch from JENA-527 to mitigate test hang issues for JDBC (rvesse: rev 1519506) * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/TS_JdbcDriverRemote.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/AbstractRemoteEndpointResultSetTests.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/TestRemoteEndpointResults.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/TestRemoteEndpointResultsWithAuth.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/TestRemoteEndpointResultsWithGraphUris.java * /jena/trunk/jena-jdbc/jena-jdbc-driver-remote/src/test/java/org/apache/jena/jdbc/remote/results/TestRemoteEndpointResultsWithResultSetTypes.java The jena-jdbc test suite does not reliably run on Java6 --- Key: JENA-527 URL: https://issues.apache.org/jira/browse/JENA-527 Project: Apache Jena Issue Type: Bug Components: JDBC Affects Versions: Jena 2.11.0 Reporter: Andy Seaborne Attachments: jdbc-testing-v1.patch The test suite does not run reliably on java6. It seems that socket resources in the kernel are being allocated and then need a timeout before the kernel has resources again. But the test suite runs to fast and will lock up waiting. Sometimes sockets in state ESTABLISHED are left around. This also leads to lock-up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-523) DatasetGraphWithLock throws exception on abort but this can occur in Fuseki
[ https://issues.apache.org/jira/browse/JENA-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753917#comment-13753917 ] Hudson commented on JENA-523: - SUCCESS: Integrated in Jena_Development_Test #887 (See [https://builds.apache.org/job/Jena_Development_Test/887/]) JENA-523 (andy: rev 1518743) * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/HttpAction.java DatasetGraphWithLock throws exception on abort but this can occur in Fuseki --- Key: JENA-523 URL: https://issues.apache.org/jira/browse/JENA-523 Project: Apache Jena Issue Type: Bug Components: ARQ, Fuseki Reporter: Andy Seaborne Assignee: Andy Seaborne Attachments: assmbler-jena-523.ttl, fuseki-errors-1.log DatasetGraphWithLock can not support a proper abort (no rollback). But some action, like a parse error in SPARQL Update in Fuseki, cause an abort. The abort there causes the internal state to become inconsistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-525) OntDocuemntManager copies the FileManger incorrectly.
[
https://issues.apache.org/jira/browse/JENA-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752404#comment-13752404
]
Hudson commented on JENA-525:
-
SUCCESS: Integrated in Jena_Development_Test #876 (See
[https://builds.apache.org/job/Jena_Development_Test/876/])
JENA-525 : Add cloning operation for AdapterFileManager.
Set the global location mapper with the global StreamManager. (andy: rev
1518203)
*
/jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/adapters/AdapterFileManager.java
*
/jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/stream/StreamManager.java
OntDocuemntManager copies the FileManger incorrectly.
-
Key: JENA-525
URL: https://issues.apache.org/jira/browse/JENA-525
Project: Apache Jena
Issue Type: Bug
Components: Ontology API
Affects Versions: Jena 2.10.1
Reporter: Andy Seaborne
Assignee: Andy Seaborne
From
http://mail-archives.apache.org/mod_mbox/jena-users/201308.mbox/%3C521D6121.3070503%40neusoft.com%3E
The OntDocumentManager takes its own copy of a FileManager -- but as of jena
2.10.1 the actual global filemanager is a subclass of FileManager. When
OntDocumentManager recreates a copy, the copy is incomplete. Need to copy
the subclass somehow.
Problem code: {{new FileManager}} in:
{noformat}
public void setFileManager() {
setFileManager( new FileManager( FileManager.get() ) );
m_usingGlobalFileMgr = true;
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-525) OntDocuemntManager copies the FileManger incorrectly.
[
https://issues.apache.org/jira/browse/JENA-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752502#comment-13752502
]
Hudson commented on JENA-525:
-
SUCCESS: Integrated in Jena_Development_Test #877 (See
[https://builds.apache.org/job/Jena_Development_Test/877/])
JENA-525 : Add cloning operation for the (new) LocationMapper.
Reformat. (andy: rev 1518255)
*
/jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/adapters/AdapterFileManager.java
*
/jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/stream/LocationMapper.java
*
/jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/stream/StreamManager.java
*
/jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/adapters/TestFileManager.java
OntDocuemntManager copies the FileManger incorrectly.
-
Key: JENA-525
URL: https://issues.apache.org/jira/browse/JENA-525
Project: Apache Jena
Issue Type: Bug
Components: Ontology API
Affects Versions: Jena 2.10.1
Reporter: Andy Seaborne
Assignee: Andy Seaborne
From
http://mail-archives.apache.org/mod_mbox/jena-users/201308.mbox/%3C521D6121.3070503%40neusoft.com%3E
The OntDocumentManager takes its own copy of a FileManager -- but as of jena
2.10.1 the actual global filemanager is a subclass of FileManager. When
OntDocumentManager recreates a copy, the copy is incomplete. Need to copy
the subclass somehow.
Problem code: {{new FileManager}} in:
{noformat}
public void setFileManager() {
setFileManager( new FileManager( FileManager.get() ) );
m_usingGlobalFileMgr = true;
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-523) DatasetGraphWithLock throws exception on abort but this can occur in Fuseki
[ https://issues.apache.org/jira/browse/JENA-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752878#comment-13752878 ] Hudson commented on JENA-523: - SUCCESS: Integrated in Jena_Development_Test #880 (See [https://builds.apache.org/job/Jena_Development_Test/880/]) JENA-523 : Don't use transactional mode on transaction-by-lock. (andy: rev 1518367) * /jena/trunk/jena-fuseki/run_cp * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/HttpAction.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Update.java JENA-523 : Clean up even when abort is called. (andy: rev 1518353) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/core/DatasetGraphWithLock.java DatasetGraphWithLock throws exception on abort but this can occur in Fuseki --- Key: JENA-523 URL: https://issues.apache.org/jira/browse/JENA-523 Project: Apache Jena Issue Type: Bug Components: ARQ, Fuseki Reporter: Andy Seaborne Assignee: Andy Seaborne Attachments: assmbler-jena-523.ttl, fuseki-errors-1.log DatasetGraphWithLock can not support a proper abort (no rollback). But some action, like a parse error in SPARQL Update in Fuseki, cause an abort. The abort there causes the internal state to become inconsistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-522) DatasetGraphWithLock claims to support multiple readers but appears not to
[
https://issues.apache.org/jira/browse/JENA-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13750790#comment-13750790
]
Hudson commented on JENA-522:
-
FAILURE: Integrated in Jena_Development_Test #871 (See
[https://builds.apache.org/job/Jena_Development_Test/871/])
Regression tests for JENA-522 (rvesse: rev 1517729)
* /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/core/TS_Core.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/core/TestDatasetGraphWithLock.java
Fix for a test clean up bug that was highlighted by the JENA-522 changes
(rvesse: rev 1517724)
*
/jena/trunk/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jdbc/connections/DatasetConnection.java
*
/jena/trunk/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jdbc/connections/JenaConnection.java
*
/jena/trunk/jena-jdbc/jena-jdbc-driver-tdb/src/test/java/org/apache/jena/jdbc/tdb/results/AbstractTdbResultSetTests.java
DatasetGraphWithLock claims to support multiple readers but appears not to
--
Key: JENA-522
URL: https://issues.apache.org/jira/browse/JENA-522
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 2.10.2
Reporter: Rob Vesse
Assignee: Andy Seaborne
Labels: concurrency, lock, multi-threading
Fix For: Jena 2.10.2
Attachments: JENA-522.patch
This bug originates out of a StackOverflow question pertaining to jena-text
http://stackoverflow.com/q/18385738/107591
However upon investigation the culprit appears to be
{{DatasetGraphWithLock}}, reproducing my analysis from my SO answer here:
{quote}
The issue is that the dataset with inference implicitly uses ARQ's standard
in-memory Dataset implementation and this does not support transactions.
However text datasets which correspond to {{DatasetGraphText}} internally
(and in your stack trace) requires the wrapped dataset to support
transactions and where they do not wraps them with {{DatasetGraphWithLock}}.
It is this that appears to be encountering the problem with the lock, the
documentation states that this should support multiple readers but having
followed the logic of the code I'm not sure that it actually allows this.
{quote}
I put together the following test case which illustrates the issue:
{noformat}
@Test
public synchronized void dsg_with_lock_concurrency_02() throws
InterruptedException, ExecutionException, TimeoutException {
ExecutorService executor = Executors.newCachedThreadPool();
try {
final DatasetGraphWithLock dsg = new
DatasetGraphWithLock(DatasetGraphFactory.createMem());
CallableBoolean callable = new CallableBoolean() {
@Override
public Boolean call() throws Exception {
// Get a read lock
dsg.begin(ReadWrite.READ);
// Hold the lock for a short time
try {
Thread.sleep(500);
} catch (InterruptedException e) {
// Ignore error
}
// Release the lock
dsg.commit();
return true;
}
};
// Run the callable a bunch of times
ListFutureBoolean futures = new ArrayListFutureBoolean();
for (int i = 0; i 100; i++) {
futures.add(executor.submit(callable));
}
// Check all the futures come back OK
for (FutureBoolean f : futures) {
Assert.assertTrue(f.get(3, TimeUnit.SECONDS));
}
} finally {
executor.shutdownNow();
}
}
{noformat}
So the problem appears to be that DatasetGraphWithLock claims multi-reader
support but in reality does not allow this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-522) DatasetGraphWithLock claims to support multiple readers but appears not to
[
https://issues.apache.org/jira/browse/JENA-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13750829#comment-13750829
]
Hudson commented on JENA-522:
-
ABORTED: Integrated in Jena_JDBC_Test #15 (See
[https://builds.apache.org/job/Jena_JDBC_Test/15/])
Fix for a test clean up bug that was highlighted by the JENA-522 changes
(rvesse: rev 1517724)
*
/jena/trunk/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jdbc/connections/DatasetConnection.java
*
/jena/trunk/jena-jdbc/jena-jdbc-core/src/main/java/org/apache/jena/jdbc/connections/JenaConnection.java
*
/jena/trunk/jena-jdbc/jena-jdbc-driver-tdb/src/test/java/org/apache/jena/jdbc/tdb/results/AbstractTdbResultSetTests.java
DatasetGraphWithLock claims to support multiple readers but appears not to
--
Key: JENA-522
URL: https://issues.apache.org/jira/browse/JENA-522
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 2.10.2
Reporter: Rob Vesse
Assignee: Andy Seaborne
Labels: concurrency, lock, multi-threading
Fix For: Jena 2.10.2
Attachments: JENA-522.patch
This bug originates out of a StackOverflow question pertaining to jena-text
http://stackoverflow.com/q/18385738/107591
However upon investigation the culprit appears to be
{{DatasetGraphWithLock}}, reproducing my analysis from my SO answer here:
{quote}
The issue is that the dataset with inference implicitly uses ARQ's standard
in-memory Dataset implementation and this does not support transactions.
However text datasets which correspond to {{DatasetGraphText}} internally
(and in your stack trace) requires the wrapped dataset to support
transactions and where they do not wraps them with {{DatasetGraphWithLock}}.
It is this that appears to be encountering the problem with the lock, the
documentation states that this should support multiple readers but having
followed the logic of the code I'm not sure that it actually allows this.
{quote}
I put together the following test case which illustrates the issue:
{noformat}
@Test
public synchronized void dsg_with_lock_concurrency_02() throws
InterruptedException, ExecutionException, TimeoutException {
ExecutorService executor = Executors.newCachedThreadPool();
try {
final DatasetGraphWithLock dsg = new
DatasetGraphWithLock(DatasetGraphFactory.createMem());
CallableBoolean callable = new CallableBoolean() {
@Override
public Boolean call() throws Exception {
// Get a read lock
dsg.begin(ReadWrite.READ);
// Hold the lock for a short time
try {
Thread.sleep(500);
} catch (InterruptedException e) {
// Ignore error
}
// Release the lock
dsg.commit();
return true;
}
};
// Run the callable a bunch of times
ListFutureBoolean futures = new ArrayListFutureBoolean();
for (int i = 0; i 100; i++) {
futures.add(executor.submit(callable));
}
// Check all the futures come back OK
for (FutureBoolean f : futures) {
Assert.assertTrue(f.get(3, TimeUnit.SECONDS));
}
} finally {
executor.shutdownNow();
}
}
{noformat}
So the problem appears to be that DatasetGraphWithLock claims multi-reader
support but in reality does not allow this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-201) Deliver Fuseki as a WAR file.
[ https://issues.apache.org/jira/browse/JENA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749700#comment-13749700 ] Hudson commented on JENA-201: - SUCCESS: Integrated in Jena_Development_Test #868 (See [https://builds.apache.org/job/Jena_Development_Test/868/]) Refactor to make the HttpAction objects and servlets independent of Jetty. An indirect dependency existed for HttpAction on SPARQLServer. Refactoring is a step towards JENA-201 (Deliver Fuseki as a WAR file). (andy: rev 1517341) * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/Fuseki.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/SPARQLServer.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_ServletBase.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_UberServlet.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/ServletBase.java Deliver Fuseki as a WAR file. - Key: JENA-201 URL: https://issues.apache.org/jira/browse/JENA-201 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Andy Seaborne Priority: Minor Labels: gsoc2013, mentor Attachments: GruppoImola_fuseki_war_src.rar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-517) Unhandled IOException during model write to OutputStream
[
https://issues.apache.org/jira/browse/JENA-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13748650#comment-13748650
]
Hudson commented on JENA-517:
-
SUCCESS: Integrated in Jena_Development_Test #861 (See
[https://builds.apache.org/job/Jena_Development_Test/861/])
JENA-517 (andy: rev 1516894)
* /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/n3/N3IndentedWriter.java
* /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/n3/N3JenaWriter.java
* /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/n3/N3JenaWriterCommon.java
Unhandled IOException during model write to OutputStream
Key: JENA-517
URL: https://issues.apache.org/jira/browse/JENA-517
Project: Apache Jena
Issue Type: Bug
Components: Jena
Affects Versions: Jena 2.10.1
Reporter: Knut-Olav Hoven
Assignee: Andy Seaborne
Priority: Minor
Fix For: Jena 2.10.2
Method N3JenaWriterCommon.write() silently ignores IOException from
Writer.flush() while writing a model to an OutputStream.
This might lead to debugging nightmares.
Should at the very least throw some runtime exception wrapping the original
exception :)
{code}
@Override
public synchronized void write(Model model, OutputStream output, String
base)
{
try {
Writer w = new BufferedWriter(new
OutputStreamWriter(output, UTF-8)) ;
write(model, w, base) ;
try { w.flush() ; } catch (IOException ioEx) {}
} catch (java.io.UnsupportedEncodingException ex)
{
System.err.println(Failed to create UTF-8 writer) ;
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-521) IO_Jena.resetJena() does not reset RDF/XML
[ https://issues.apache.org/jira/browse/JENA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13748783#comment-13748783 ] Hudson commented on JENA-521: - UNSTABLE: Integrated in Jena_Development_Test #862 (See [https://builds.apache.org/job/Jena_Development_Test/862/]) JENA-520 and JENA-521 (andy: rev 1516942) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/system/IO_JenaReaders.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/system/IO_JenaWriters.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/system/TS_RiotSystem.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/system/TestIO_JenaReaders.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/system/TestIO_JenaWriters.java IO_Jena.resetJena() does not reset RDF/XML --- Key: JENA-521 URL: https://issues.apache.org/jira/browse/JENA-521 Project: Apache Jena Issue Type: Bug Components: RIOT Affects Versions: Jena 2.10.1 Reporter: Stian Soiland-Reyes Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.10.2 IO_JenaReaders.resetJena() - called by IO_Jena.resetJena() - did not reset RDF/XML and RDF/XML-Abbrev. Similarly, IO_JenaWriters.resetJena() did not reset NT, RDF/JSON or RDFJSON. My suggested patch is at https://github.com/apache/jena/pull/2/files This patch includes full tests of both registering and resetting, and also fixes JENA-520 nullpointerexception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-522) DatasetGraphWithLock claims to support multiple readers but appears not to
[
https://issues.apache.org/jira/browse/JENA-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13748864#comment-13748864
]
Hudson commented on JENA-522:
-
SUCCESS: Integrated in Jena_Development_Test #863 (See
[https://builds.apache.org/job/Jena_Development_Test/863/])
JENA-522 : use thread local for recording transaction state. (andy: rev 1516970)
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/core/DatasetGraphTrackActive.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/core/DatasetGraphWithLock.java
DatasetGraphWithLock claims to support multiple readers but appears not to
--
Key: JENA-522
URL: https://issues.apache.org/jira/browse/JENA-522
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 2.10.2
Reporter: Rob Vesse
Assignee: Andy Seaborne
Labels: concurrency, lock, multi-threading
Fix For: Jena 2.10.2
Attachments: JENA-522.patch
This bug originates out of a StackOverflow question pertaining to jena-text
http://stackoverflow.com/q/18385738/107591
However upon investigation the culprit appears to be
{{DatasetGraphWithLock}}, reproducing my analysis from my SO answer here:
{quote}
The issue is that the dataset with inference implicitly uses ARQ's standard
in-memory Dataset implementation and this does not support transactions.
However text datasets which correspond to {{DatasetGraphText}} internally
(and in your stack trace) requires the wrapped dataset to support
transactions and where they do not wraps them with {{DatasetGraphWithLock}}.
It is this that appears to be encountering the problem with the lock, the
documentation states that this should support multiple readers but having
followed the logic of the code I'm not sure that it actually allows this.
{quote}
I put together the following test case which illustrates the issue:
{noformat}
@Test
public synchronized void dsg_with_lock_concurrency_02() throws
InterruptedException, ExecutionException, TimeoutException {
ExecutorService executor = Executors.newCachedThreadPool();
try {
final DatasetGraphWithLock dsg = new
DatasetGraphWithLock(DatasetGraphFactory.createMem());
CallableBoolean callable = new CallableBoolean() {
@Override
public Boolean call() throws Exception {
// Get a read lock
dsg.begin(ReadWrite.READ);
// Hold the lock for a short time
try {
Thread.sleep(500);
} catch (InterruptedException e) {
// Ignore error
}
// Release the lock
dsg.commit();
return true;
}
};
// Run the callable a bunch of times
ListFutureBoolean futures = new ArrayListFutureBoolean();
for (int i = 0; i 100; i++) {
futures.add(executor.submit(callable));
}
// Check all the futures come back OK
for (FutureBoolean f : futures) {
Assert.assertTrue(f.get(3, TimeUnit.SECONDS));
}
} finally {
executor.shutdownNow();
}
}
{noformat}
So the problem appears to be that DatasetGraphWithLock claims multi-reader
support but in reality does not allow this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-521) IO_Jena.resetJena() does not reset RDF/XML
[ https://issues.apache.org/jira/browse/JENA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13748863#comment-13748863 ] Hudson commented on JENA-521: - SUCCESS: Integrated in Jena_Development_Test #863 (See [https://builds.apache.org/job/Jena_Development_Test/863/]) JENA_520 and JENA-521 -- stablize testing by setting IO state after the tests run (andy: rev 1516961) * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/system/TestIO_JenaReaders.java * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/system/TestIO_JenaWriters.java IO_Jena.resetJena() does not reset RDF/XML --- Key: JENA-521 URL: https://issues.apache.org/jira/browse/JENA-521 Project: Apache Jena Issue Type: Bug Components: RIOT Affects Versions: Jena 2.10.1 Reporter: Stian Soiland-Reyes Assignee: Andy Seaborne Priority: Minor Fix For: Jena 2.10.2 IO_JenaReaders.resetJena() - called by IO_Jena.resetJena() - did not reset RDF/XML and RDF/XML-Abbrev. Similarly, IO_JenaWriters.resetJena() did not reset NT, RDF/JSON or RDFJSON. My suggested patch is at https://github.com/apache/jena/pull/2/files This patch includes full tests of both registering and resetting, and also fixes JENA-520 nullpointerexception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-507) Add support for Leviathan extension functions to ARQ
[ https://issues.apache.org/jira/browse/JENA-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747667#comment-13747667 ] Hudson commented on JENA-507: - SUCCESS: Integrated in Jena_Development_Test #856 (See [https://builds.apache.org/job/Jena_Development_Test/856/]) Updated tests for Leviathan functions (JENA-507) (rvesse: rev 1516516) * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/expr/TestLeviathanFunctions.java Add the Leviathan pow(?x, ?power) function (JENA-507) (rvesse: rev 1516515) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/library/leviathan/cube.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/library/leviathan/e.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/library/leviathan/pow.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/library/leviathan/sq.java Add support for Leviathan extension functions to ARQ Key: JENA-507 URL: https://issues.apache.org/jira/browse/JENA-507 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Rob Vesse Assignee: Rob Vesse Labels: extension, functions, sparql Original Estimate: 336h Time Spent: 4h Remaining Estimate: 332h The Leviathan Function library is a set of extension functions present in dotNetRDF's SPARQL engine. It contains a useful set of numeric functions which would be useful to have available in core ARQ and would boost portability of queries between ARQ and dotNetRDF (note that dotNetRDF already supports ARQs extension functions). See https://bitbucket.org/dotnetrdf/dotnetrdf/wiki/DeveloperGuide/SPARQL/Leviathan%20Functions for definition of functions Note that some of these overlap with new XPath 3 functions but for portability purposes there is no reason not to support these as well since most are relatively trivial to implement. I will file a separate issue for supporting XPath 3 functions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-519) Add initial binding support to update queries
[ https://issues.apache.org/jira/browse/JENA-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13746582#comment-13746582 ] Hudson commented on JENA-519: - SUCCESS: Integrated in Jena_Development_Test #852 (See [https://builds.apache.org/job/Jena_Development_Test/852/]) JENA-519 Add initial binding support to update queries (sallen: rev 1516220) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateEngineBase.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateEngineFactory.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateEngineMain.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateEngineNonStreaming.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateEngineWorker.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessorBase.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessorStreamingBase.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/update/UpdateAction.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/update/UpdateExecutionFactory.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/modify/AbstractTestUpdateGraph.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/modify/UpdateEngineSDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/modify/UpdateEngineTDB.java Add initial binding support to update queries - Key: JENA-519 URL: https://issues.apache.org/jira/browse/JENA-519 Project: Apache Jena Issue Type: Improvement Reporter: Stephen Allen Assignee: Stephen Allen Priority: Minor Attachments: JENA-519.patch SPARQL update queries lost the ability to specify initial bindings. The patch will add that functionality (note that initial bindings are only meaningful for INSERT/DELETE/WHERE and DELETE/WHERE update queries. Note that this changes the API for 3rd party UpdateEngine implementers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-519) Add initial binding support to update queries
[ https://issues.apache.org/jira/browse/JENA-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13746591#comment-13746591 ] Hudson commented on JENA-519: - SUCCESS: Integrated in Jena_Development_Test #853 (See [https://builds.apache.org/job/Jena_Development_Test/853/]) Add JENA-519 to ARQ Release Notes (sallen: rev 1516225) * /jena/trunk/jena-arq/ReleaseNotes.txt Add initial binding support to update queries - Key: JENA-519 URL: https://issues.apache.org/jira/browse/JENA-519 Project: Apache Jena Issue Type: Improvement Reporter: Stephen Allen Assignee: Stephen Allen Priority: Minor Attachments: JENA-519.patch SPARQL update queries lost the ability to specify initial bindings. The patch will add that functionality (note that initial bindings are only meaningful for INSERT/DELETE/WHERE and DELETE/WHERE update queries. Note that this changes the API for 3rd party UpdateEngine implementers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-519) Add initial binding support to update queries
[ https://issues.apache.org/jira/browse/JENA-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13746660#comment-13746660 ] Hudson commented on JENA-519: - SUCCESS: Integrated in Jena_Development_Test #854 (See [https://builds.apache.org/job/Jena_Development_Test/854/]) JENA-519 : Add QuerySolution versions of API operations taking an initial Binding. (andy: rev 1516234) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/update/UpdateAction.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/update/UpdateExecutionFactory.java Add initial binding support to update queries - Key: JENA-519 URL: https://issues.apache.org/jira/browse/JENA-519 Project: Apache Jena Issue Type: Improvement Reporter: Stephen Allen Assignee: Stephen Allen Priority: Minor Attachments: JENA-519.patch SPARQL update queries lost the ability to specify initial bindings. The patch will add that functionality (note that initial bindings are only meaningful for INSERT/DELETE/WHERE and DELETE/WHERE update queries. Note that this changes the API for 3rd party UpdateEngine implementers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-514) Add remove() operation support on iterators of triple/quad
[ https://issues.apache.org/jira/browse/JENA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13743386#comment-13743386 ] Hudson commented on JENA-514: - SUCCESS: Integrated in Jena_Development_Test #850 (See [https://builds.apache.org/job/Jena_Development_Test/850/]) JENA-513 , JENA-514 : DatasetGraphBase.deleteAny rewritten to work in slices. Instead of copying the whole iterator, the code takes slices, and repeats until the deleteAny pattern no longer causes .find to return anything. (andy: rev 1515213) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/core/DatasetGraphBase.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/core/AbstractDatasetGraphTests.java Add remove() operation support on iterators of triple/quad -- Key: JENA-514 URL: https://issues.apache.org/jira/browse/JENA-514 Project: Apache Jena Issue Type: Brainstorming Components: TDB Affects Versions: TDB 0.10.1 Reporter: Knut-Olav Hoven Attachments: 0001-Applied-changes-to-how-deletion-of-triples-quads-are.patch, 0002-Need-to-promote-block-before-writing-it-to-avoid-get.patch By implementing remove() operation it will fix the issue of loading all objects in memory before deleting them one by one. It will not fix the issue of keeping all write blocks in memory inside BlockMgrJournal. Ref. email on dev-mailinglist: http://mail-archives.apache.org/mod_mbox/jena-dev/201308.mbox/%3CCAKha0wqFOgR_OVFUhzTiDLML5VfSMW8zdrNfFUbk2Bnktzj_Bg%40mail.gmail.com%3E (will supply patch soon) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-516) Fuseki should use dataset transactions where available, not parse to an intermediate datastructure
[ https://issues.apache.org/jira/browse/JENA-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742893#comment-13742893 ] Hudson commented on JENA-516: - SUCCESS: Integrated in Jena_Development_Test #847 (See [https://builds.apache.org/job/Jena_Development_Test/847/]) JENA-516 Clean up Graph Store Protocol PUT and POST with streaming transactions. Structure upload better - this not streaming due to limitations of HTTP; the graph name can come after the data in the multi-part body. (andy: rev 1514974) * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/FusekiLib.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Query.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_REST.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_REST_RW.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Update.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Upload.java Fuseki should use dataset transactions where available, not parse to an intermediate datastructure -- Key: JENA-516 URL: https://issues.apache.org/jira/browse/JENA-516 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 0.2.7 Reporter: Andy Seaborne Assignee: Andy Seaborne Fix For: Fuseki 0.2.8 Fuseki should detect when an update operation is on a real transactional dataset and avoid parsing the data into a RAM as a validation step. This is especially the case for Graph Store Protocol operations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-516) Fuseki should use dataset transactions where available, not parse to an intermediate datastructure
[ https://issues.apache.org/jira/browse/JENA-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742675#comment-13742675 ] Hudson commented on JENA-516: - SUCCESS: Integrated in Jena_Development_Test #846 (See [https://builds.apache.org/job/Jena_Development_Test/846/]) JENA-516 : Graph Store Protocol PUT and POST use transactions where available (e.g. TDB). (andy: rev 1514908) * /jena/trunk/jena-fuseki/src-dev/dev/RunFuseki.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/HttpAction.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_REST.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_REST_RW.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Upload.java Fuseki should use dataset transactions where available, not parse to an intermediate datastructure -- Key: JENA-516 URL: https://issues.apache.org/jira/browse/JENA-516 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 0.2.7 Reporter: Andy Seaborne Fuseki should detect when an update operation is on a real transactional dataset and avoid parsing the data into a RAM as a validation step. This is especially the case for Graph Store Protocol operations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-510) Incorrect content negotiation with */* in Accept header
[
https://issues.apache.org/jira/browse/JENA-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739628#comment-13739628
]
Hudson commented on JENA-510:
-
SUCCESS: Integrated in Jena_Development_Test #837 (See
[https://builds.apache.org/job/Jena_Development_Test/837/])
JENA-510 : Rewrite content negiotiation code; remove ability to offer ranges
(does not make sense).
Check tests and make all valid; add tests for specific common usages. (andy:
rev 1513851)
* /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/AcceptList.java
* /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/MediaRange.java
*
/jena/trunk/jena-arq/src/test/java/org/apache/jena/atlas/web/TestContentNegotiation.java
Incorrect content negotiation with */* in Accept header
---
Key: JENA-510
URL: https://issues.apache.org/jira/browse/JENA-510
Project: Apache Jena
Issue Type: Bug
Components: ARQ, Fuseki, TDB
Affects Versions: Jena 2.10.1, Fuseki 0.2.7
Reporter: Sarven Capadisli
Assignee: Andy Seaborne
Priority: Minor
Fix For: Jena 2.10.2
If I'm not mistaken, when */* content type is used in Accept header, content
negotiation is incorrect. For curl -X GET
http://sparql.org/books/sparql?query=SELECT+*+WHERE+%7B+%3Fs+%3Fp+%3Fo+%7D+LIMIT+1
compare:
{noformat}
application/sparql-results+json=
application/sparql-results+json
application/sparql-results+json;q=0.1 =
application/sparql-results+json
*/*=
application/sparql-results+json
*/*;q=0.1 =
application/sparql-results+json
application/sparql-results+json;q=0.1, */*;q=0.9 =
application/sparql-results+json
application/sparql-results+json;q=0.9, */*;q=0.1 = text/csv
application/sparql-results+json;q=0.9, */*;q=0.9 = text/csv
{noformat}
It appears to be that, if the q-value of these two content-types are
compared, the output content-type is incorrect.
Here is an awkward one:
{noformat}
application/sparql-results+xml;q=0.1, */*;q=0.9=
application/sparql-results+json
application/sparql-results+xml;q=0.9, */*;q=0.1=
application/sparql-results+json
application/sparql-results+xml;q=0.9, */*;q=0.9=
application/sparql-results+json
{noformat}
What's going on now?
Just for completeness:
{noformat}
application/sparql-results+xml;q=0.1, application/sparql-results+json;q=0.9
= application/sparql-results+json
application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.1
= application/sparql-results+xml
application/sparql-results+xml;q=0.9, application/sparql-results+json;q=0.9
= application/sparql-results+json
{noformat}
That looks okay.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740429#comment-13740429 ] Hudson commented on JENA-512: - SUCCESS: Integrated in Jena_Development_Test #838 (See [https://builds.apache.org/job/Jena_Development_Test/838/]) Add unit tests for isNumeric case (JENA-512) (rvesse: rev 1514087) * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/syntax/TestSSE_Builder.java Add Tags.tagIsNumeric and associated SSE builder (JENA-512) (rvesse: rev 1514086) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/Tags.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/builders/BuilderExpr.java SSE Tags are used inconsistently Key: JENA-512 URL: https://issues.apache.org/jira/browse/JENA-512 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Reporter: Rob Vesse Assignee: Rob Vesse Priority: Minor Labels: algebra, sse In some of our more recent code we are trying to map functions into a messaging data structure by inspecting the function symbol. However we have found that there are some inconsistencies in the symbols. Namely that the capitalization and punctuation are not consistent, likely this cannot change as it would mean breaking many existing algebra examples/tests and systems like ours that use algebra strings internally. The more concerning inconsistencies are that some functions report symbols without using the tag constants and so some queries written report symbols that don't match their tag constants. BuilderExpr appears to get around this by doing case insensitive key lookup which seems very hacky There is also at least one function (isNumeric) which has no Tag constant and no SSE builder defined for it so queries containing this cannot be decoded from algebra. I plan to do two things: - Make expression classes return their Tags constant where they don't already and particularly in the cases where the two values aren't exact matches - Fix the isNumeric case (and any others I discover) where there is no registered builder for the symbol -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-512) SSE Tags are used inconsistently
[ https://issues.apache.org/jira/browse/JENA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740467#comment-13740467 ] Hudson commented on JENA-512: - FAILURE: Integrated in Jena_Development_Test #839 (See [https://builds.apache.org/job/Jena_Development_Test/839/]) Use correct Tags constant for E_UnaryMinus (JENA-512) (rvesse: rev 1514101) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryMinus.java Ensure SPARQL built-in expressions use symbol constants from Tags wherever possible instead of hard coding values in each file (JENA-512) (rvesse: rev 1514099) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Add.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_BNode.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Bound.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Call.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Coalesce.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Conditional.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Datatype.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Divide.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Equals.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Exists.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_GreaterThan.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_GreaterThanOrEqual.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IRI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsBlank.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsIRI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsLiteral.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsNumeric.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_IsURI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Lang.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LangMatches.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LessThan.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LessThanOrEqual.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalAnd.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalNot.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_LogicalOr.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Multiply.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotEquals.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotExists.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_NotOneOf.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_OneOf.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Random.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Regex.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_SameTerm.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Str.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_StrConcat.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_StrDatatype.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_StrLang.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_Subtract.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_URI.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryMinus.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/E_UnaryPlus.java SSE Tags are used inconsistently Key: JENA-512 URL: https://issues.apache.org/jira/browse/JENA-512 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Reporter: Rob Vesse Assignee: Rob Vesse Priority: Minor Labels: algebra, sse In some of our more recent code we are trying to map functions into a messaging data structure by inspecting the function symbol. However we have found that there are some inconsistencies in the symbols. Namely that the capitalization and punctuation are not consistent, likely this cannot change as it would mean breaking many existing algebra examples/tests and systems like ours that use algebra strings internally. The more concerning inconsistencies are that some functions report symbols without using the tag constants and so some queries written
[jira] [Commented] (JENA-498) Multiple repeated use of HttpOp.execHttpPost leads to No buffer space available (maximum connections reached?)
[ https://issues.apache.org/jira/browse/JENA-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734750#comment-13734750 ] Hudson commented on JENA-498: - SUCCESS: Integrated in Jena_Development_Test #820 (See [https://builds.apache.org/job/Jena_Development_Test/820/]) Clear up for JENA-498 This setup has shown the best stability. (andy: rev 1512291) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java Multiple repeated use of HttpOp.execHttpPost leads to No buffer space available (maximum connections reached?) Key: JENA-498 URL: https://issues.apache.org/jira/browse/JENA-498 Project: Apache Jena Issue Type: Bug Components: RIOT Affects Versions: Jena 2.10.1, Fuseki 0.2.7 Reporter: Andy Seaborne Assignee: Andy Seaborne Fix For: Jena 2.10.2 From http://mail-archives.apache.org/mod_mbox/jena-users/201308.mbox/%3CCAE5DGJjODJJ-o5t4gJCGqc6mXPyLgDbsDgD%2BxM0eU6WZVacbbw%40mail.gmail.com%3E See http://stackoverflow.com/questions/6068423/java-net-socketexception-no-buffer-space-available-maximum-connections-reached Things to check: * The SO link suggests having only one HttpClient. * Make sure the POST is closed (entity consumed) * Call HttpRequestBase.reset() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-498) Multiple repeated use of HttpOp.execHttpPost leads to No buffer space available (maximum connections reached?)
[ https://issues.apache.org/jira/browse/JENA-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13735056#comment-13735056 ] Hudson commented on JENA-498: - SUCCESS: Integrated in Jena_Development_Test #824 (See [https://builds.apache.org/job/Jena_Development_Test/824/]) Take care to recycle HttpClient's created in QueryEngineHTTP (JENA-498) (rvesse: rev 1512409) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/http/HttpQuery.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/http/QueryEngineHTTP.java Multiple repeated use of HttpOp.execHttpPost leads to No buffer space available (maximum connections reached?) Key: JENA-498 URL: https://issues.apache.org/jira/browse/JENA-498 Project: Apache Jena Issue Type: Bug Components: RIOT Affects Versions: Jena 2.10.1, Fuseki 0.2.7 Reporter: Andy Seaborne Assignee: Andy Seaborne Fix For: Jena 2.10.2 From http://mail-archives.apache.org/mod_mbox/jena-users/201308.mbox/%3CCAE5DGJjODJJ-o5t4gJCGqc6mXPyLgDbsDgD%2BxM0eU6WZVacbbw%40mail.gmail.com%3E See http://stackoverflow.com/questions/6068423/java-net-socketexception-no-buffer-space-available-maximum-connections-reached Things to check: * The SO link suggests having only one HttpClient. * Make sure the POST is closed (entity consumed) * Call HttpRequestBase.reset() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-507) Add support for Leviathan extension functions to ARQ
[ https://issues.apache.org/jira/browse/JENA-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13735100#comment-13735100 ] Hudson commented on JENA-507: - SUCCESS: Integrated in Jena_Development_Test #825 (See [https://builds.apache.org/job/Jena_Development_Test/825/]) Initial unit tests for Leviathan extension functions (JENA-507) (rvesse: rev 1512418) * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/expr/TestFunctions.java * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/expr/TestLeviathanFunctions.java Initial implementation support for a few Leviathan extension functions (JENA-507) (rvesse: rev 1512416) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/nodevalue/NumericType.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/library/leviathan * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/library/leviathan/LeviathanConstants.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/library/leviathan/cube.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/library/leviathan/e.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/library/leviathan/sq.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/util/MappedLoader.java Add support for Leviathan extension functions to ARQ Key: JENA-507 URL: https://issues.apache.org/jira/browse/JENA-507 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Rob Vesse Assignee: Rob Vesse Labels: extension, functions, sparql Original Estimate: 336h Time Spent: 4h Remaining Estimate: 332h The Leviathan Function library is a set of extension functions present in dotNetRDF's SPARQL engine. It contains a useful set of numeric functions which would be useful to have available in core ARQ and would boost portability of queries between ARQ and dotNetRDF (note that dotNetRDF already supports ARQs extension functions). See https://bitbucket.org/dotnetrdf/dotnetrdf/wiki/DeveloperGuide/SPARQL/Leviathan%20Functions for definition of functions Note that some of these overlap with new XPath 3 functions but for portability purposes there is no reason not to support these as well since most are relatively trivial to implement. I will file a separate issue for supporting XPath 3 functions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-500) SPARQL optimizer does not consider pre-bound variables, creates wrong query
[ https://issues.apache.org/jira/browse/JENA-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13735276#comment-13735276 ] Hudson commented on JENA-500: - SUCCESS: Integrated in Jena_Development_Test #827 (See [https://builds.apache.org/job/Jena_Development_Test/827/]) Change comments on JENA-500 test cases to reflect reality (rvesse: rev 1512484) * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/api/TestAPI.java JENA-500 Substitute for variables before optimization. (andy: rev 1512481) * /jena/trunk/jena-arq/ReleaseNotes.txt JENA-500 Substitute for variables before optimization. (andy: rev 1512479) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/QueryEngineBase.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/main/QueryEngineMain.java SPARQL optimizer does not consider pre-bound variables, creates wrong query --- Key: JENA-500 URL: https://issues.apache.org/jira/browse/JENA-500 Project: Apache Jena Issue Type: Bug Components: Optimizer Affects Versions: Jena 2.10.2 Reporter: Holger Knublauch Assignee: Andy Seaborne Fix For: Jena 2.10.2 Attachments: TestPreboundFilter.java There is a regression bug somewhere between 2.7.2 and 2.10.2. See test case which works green in the old version but fails on the latest snapshot. I believe the cause is that TransformFilterImplicitJoin.testSpecialCaseUnused() incorrectly assumes it can ignore the whole query if it encounters unbound variables. However, in my case the variables do have values, coming from the initial binding of the QueryExecution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-498) Multiple repeated use of HttpOp.execHttpPost leads to No buffer space available (maximum connections reached?)
[ https://issues.apache.org/jira/browse/JENA-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733437#comment-13733437 ] Hudson commented on JENA-498: - ABORTED: Integrated in Jena_Development_Test #811 (See [https://builds.apache.org/job/Jena_Development_Test/811/]) Immediate fix for JENA-498 Use a common HttpClient internally; set it to do connection pooling. (andy: rev 1511682) * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java Multiple repeated use of HttpOp.execHttpPost leads to No buffer space available (maximum connections reached?) Key: JENA-498 URL: https://issues.apache.org/jira/browse/JENA-498 Project: Apache Jena Issue Type: Bug Components: RIOT Affects Versions: Jena 2.10.1, Fuseki 0.2.7 Reporter: Andy Seaborne Assignee: Andy Seaborne From http://mail-archives.apache.org/mod_mbox/jena-users/201308.mbox/%3CCAE5DGJjODJJ-o5t4gJCGqc6mXPyLgDbsDgD%2BxM0eU6WZVacbbw%40mail.gmail.com%3E See http://stackoverflow.com/questions/6068423/java-net-socketexception-no-buffer-space-available-maximum-connections-reached Things to check: * The SO link suggests having only one HttpClient. * Make sure the POST is closed (entity consumed) * Call HttpRequestBase.reset() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-502) VALUES keyword in subquery ignored in some cases.
[
https://issues.apache.org/jira/browse/JENA-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733436#comment-13733436
]
Hudson commented on JENA-502:
-
ABORTED: Integrated in Jena_Development_Test #811 (See
[https://builds.apache.org/job/Jena_Development_Test/811/])
JENA-502
Rewrite variables in tables (needed when doing a rename for nested SELECTs).
(andy: rev 1511698)
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/graph/NodeTransformLib.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/graph/NodeTransformOp.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestVarRename.java
VALUES keyword in subquery ignored in some cases.
-
Key: JENA-502
URL: https://issues.apache.org/jira/browse/JENA-502
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Affects Versions: Fuseki 0.2.7, Fuseki 0.2.8
Environment: Ubuntu 13.04 x64
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.13.04.2)
Reporter: Barry Coughlan
Assignee: Andy Seaborne
Fix For: Jena 2.10.2, Fuseki 0.2.8
Given the following data set in the graph http://test.com:
{code:title=data.ttl}
@prefix : http://example.com/
:s1 :type :thing .
:s1 :p1 :o1 .
:s2 :type :thing .
:s2 :p1 :o1, :o2 .
:s3 :type :thing .
:s3 :p1 :o2 .
{code}
{code}s-put http://localhost:3030/ds/data http://test.com data.ttl{code}
Suppose, as part of a subquery, we want to find all subjects that have (:p1
:o1):
{code}
PREFIX : http://example.com/
SELECT *
WHERE {
SELECT DISTINCT ?s WHERE {
GRAPH http://test.com {
?s :p1 ?obj .
VALUES ?obj { :o1 }
}
}
}
{code}
This returns the expected result (?s={:s1, :s2}). However when the GRAPH
statement is outside the subquery:
{code}
PREFIX : http://example.com/
SELECT *
WHERE {
GRAPH http://test.com {
SELECT DISTINCT ?s WHERE {
?s :p1 ?obj .
VALUES ?obj { :o1 }
}
}
}
{code}
this returns ?s={:p1, :p2, :p3} - the VALUES block is ignored by the query,
and removing the VALUES block gives the same result.
Going back to the first query, let's try to select all triples with subjects
restricted by the subquery:
{code}
PREFIX : http://example.com/
SELECT ?s ?p ?o
WHERE {
{SELECT DISTINCT ?s WHERE {
GRAPH http://test.com {
?s :p1 ?obj .
VALUES ?obj { :o1 }
}
}}
GRAPH http://test.com { ?s ?p ?o }
}
{code}
I expected the subquery to restrict ?s to {:s1, :s2} and the triple at the
bottom to select all triples with that subject. This behaviour works as
expected in OpenRDF Sesame. However, once again the VALUES keyword is ignored
and the following output is observed:
{code}
s p o
:s1 :type :thing
:s1 :p1 :o1
:s2 :type :thing
:s2 :p1 :o1
:s2 :p1 :o2
:s3 :type :thing
:s3 :p1 :o2
{code}
I have tried this with other triples in the subquery, and the behaviour is as
expected. It seems to be variables restricted with the VALUES keyword that
misbehave.
Another curiousity I found while trying to find a workaround. If I add the
VALUES variable to the SELECT, changing the line {code}{SELECT DISTINCT ?s
WHERE {{code} to {code}{SELECT DISTINCT ?s ?obj WHERE {{code} then I get the
expected result of only :s1 and :s2 being selected. However, this is not
suitable as a workaround because if there is more than one value in the
VALUES block, there will be duplicate values for ?s.
Sorry for the long bug report, I'm not exactly sure of what the problem is so
thought I would give as much detail as possible. I discovered this first on
0.2.7 but ran most of these tests on the 0.2.8 build from
jena-fuseki-0.2.8-20130804.075208-67-distribution.tar.gz.
Regards,
Barry
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-498) Multiple repeated use of HttpOp.execHttpPost leads to No buffer space available (maximum connections reached?)
[ https://issues.apache.org/jira/browse/JENA-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733528#comment-13733528 ] Hudson commented on JENA-498: - SUCCESS: Integrated in Jena_Development_Test #812 (See [https://builds.apache.org/job/Jena_Development_Test/812/]) Clear up for JENA-498 Per request creation of an HttpClient is still the default due to lock-up when recycled. (andy: rev 1511783) * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/http/HttpQuery.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemote.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpResponseLib.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/web/DatasetGraphAccessorHTTP.java * /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/http/TestHttpOp.java Multiple repeated use of HttpOp.execHttpPost leads to No buffer space available (maximum connections reached?) Key: JENA-498 URL: https://issues.apache.org/jira/browse/JENA-498 Project: Apache Jena Issue Type: Bug Components: RIOT Affects Versions: Jena 2.10.1, Fuseki 0.2.7 Reporter: Andy Seaborne Assignee: Andy Seaborne From http://mail-archives.apache.org/mod_mbox/jena-users/201308.mbox/%3CCAE5DGJjODJJ-o5t4gJCGqc6mXPyLgDbsDgD%2BxM0eU6WZVacbbw%40mail.gmail.com%3E See http://stackoverflow.com/questions/6068423/java-net-socketexception-no-buffer-space-available-maximum-connections-reached Things to check: * The SO link suggests having only one HttpClient. * Make sure the POST is closed (entity consumed) * Call HttpRequestBase.reset() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-241) Add support for SAP database
[ https://issues.apache.org/jira/browse/JENA-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734059#comment-13734059 ] Hudson commented on JENA-241: - FAILURE: Integrated in Jena_Development_Test #818 (See [https://builds.apache.org/job/Jena_Development_Test/818/]) Note addition of SAP support in Change Log (JENA-241) (rvesse: rev 1512054) * /jena/trunk/jena-sdb/ChangeLog.txt Apply SAP support patch from JENA-241 (rvesse: rev 1512049) * /jena/trunk/jena-sdb/Store/sdb-sap-layout1.ttl * /jena/trunk/jena-sdb/Store/sdb-sap.ttl * /jena/trunk/jena-sdb/sdb.ttl * /jena/trunk/jena-sdb/src-dev/java/dbtest/Setup.java * /jena/trunk/jena-sdb/src-dev/java/dbtest/dbsetuptest.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/StoreDesc.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/assembler/AssemblerVocab.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/assembler/StoreDescAssembler.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/compiler/SDBCompile.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/layout1/FormatterSimpleSAP.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/layout1/StoreSimpleSAP.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/layout2/hash/FmtLayout2HashSAP.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/layout2/hash/StoreTriplesNodesHashSAP.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/layout2/hash/TupleLoaderHashSAP.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/layout2/index/FmtLayout2IndexSAP.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/layout2/index/StoreTriplesNodesIndexSAP.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/layout2/index/TupleLoaderIndexSAP.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/sql/JDBC.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/sql/SAPStorageType.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/store/DatabaseType.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/store/StoreFactory.java * /jena/trunk/jena-sdb/src/main/java/com/hp/hpl/jena/sdb/util/StoreUtils.java * /jena/trunk/jena-sdb/src/main/java/sdb/cmd/ModStore.java * /jena/trunk/jena-sdb/src/test/java/com/hp/hpl/jena/sdb/test/SDBModelGraphTestSuite.java * /jena/trunk/jena-sdb/src/test/java/com/hp/hpl/jena/sdb/test/StoreCreator.java * /jena/trunk/jena-sdb/src/test/java/com/hp/hpl/jena/sdb/test/graph/TestSAPGraph.java * /jena/trunk/jena-sdb/src/test/java/com/hp/hpl/jena/sdb/test/misc/TestRegistry.java * /jena/trunk/jena-sdb/src/test/java/com/hp/hpl/jena/sdb/test/model/TestSAPModel.java * /jena/trunk/jena-sdb/src/test/java/com/hp/hpl/jena/sdb/test/update/TestStoreUpdateSAPHash.java * /jena/trunk/jena-sdb/src/test/java/com/hp/hpl/jena/sdb/test/update/TestStoreUpdateSAPIndex.java * /jena/trunk/jena-sdb/testing/StoreDesc/sap-hash.ttl * /jena/trunk/jena-sdb/testing/StoreDesc/sap-index.ttl * /jena/trunk/jena-sdb/testing/StoreDescSimple/sap-layout1.ttl * /jena/trunk/jena-sdb/testing/store-list-simple.ttl * /jena/trunk/jena-sdb/testing/store-list.ttl Add support for SAP database Key: JENA-241 URL: https://issues.apache.org/jira/browse/JENA-241 Project: Apache Jena Issue Type: Improvement Components: SDB Affects Versions: SDB 1.3.5 Reporter: Fergal Monaghan Assignee: Rob Vesse Attachments: JENA-SDB-HANA-applied.patch, JENA-SDB-HANA.patch Original Estimate: 48h Remaining Estimate: 48h I would like to contribute my complete and tested patch to make SDB compatible with SAP's new in-memory, column-store (-possible) database codenamed HANA. I followed the instructions here [1] to the letter, created the patch and tested by applying it cleanly. Now I can run SPARQL endpoints on top of SAP's DB, and I'd like everyone else to be able to do this too. I just need to check with SAP legal before I attach the patch to this issue as described at [1]. Keep up the good work guys! [1] http://incubator.apache.org/jena/getting_involved/index.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-500) SPARQL optimizer does not consider pre-bound variables, creates wrong query
[ https://issues.apache.org/jira/browse/JENA-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729656#comment-13729656 ] Hudson commented on JENA-500: - SUCCESS: Integrated in Jena_Development_Test #808 (See [https://builds.apache.org/job/Jena_Development_Test/808/]) Test related to JENA-500 (rvesse: rev 1510602) * /jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilters.java SPARQL optimizer does not consider pre-bound variables, creates wrong query --- Key: JENA-500 URL: https://issues.apache.org/jira/browse/JENA-500 Project: Apache Jena Issue Type: Bug Components: Optimizer Affects Versions: Jena 2.10.2 Reporter: Holger Knublauch Attachments: TestPreboundFilter.java There is a regression bug somewhere between 2.7.2 and 2.10.2. See test case which works green in the old version but fails on the latest snapshot. I believe the cause is that TransformFilterImplicitJoin.testSpecialCaseUnused() incorrectly assumes it can ignore the whole query if it encounters unbound variables. However, in my case the variables do have values, coming from the initial binding of the QueryExecution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-499) fuseki-server command does not accept --host argument
[
https://issues.apache.org/jira/browse/JENA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728973#comment-13728973
]
Hudson commented on JENA-499:
-
SUCCESS: Integrated in Jena_Development_Test #806 (See
[https://builds.apache.org/job/Jena_Development_Test/806/])
JENA-499 : Add --localhost to have the server only listen to the loopback
interface. (andy: rev 1510329)
* /jena/trunk/jena-fuseki/ReleaseNotes.txt
* /jena/trunk/jena-fuseki/pom.xml
* /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/FusekiCmd.java
*
/jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/FusekiConfig.java
*
/jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/SPARQLServer.java
*
/jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/ServerConfig.java
* /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/ServerTest.java
* /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/TestAuth.java
fuseki-server command does not accept --host argument
-
Key: JENA-499
URL: https://issues.apache.org/jira/browse/JENA-499
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Affects Versions: Fuseki 0.2.7
Environment: Mac OS 10.7.5
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11G63)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Reporter: Nicholas Humfrey
The Fuseki command line help describes at the {{--host}} argument is
supported:
{noformat}
fuseki-server --help
fuseki [--config=FILE] [--mem|--desc=AssemblerFile|--file=FILE] [--port PORT]
[--host HOST] /DatasetPathName
{noformat}
But when trying to use it I get an error:
{noformat}
~ $ fuseki-server --port 8080 --host 127.0.0.1 --mem /data
Unknown argument: host
{noformat}
The {{--host}} argument is also documented here:
http://jena.apache.org/documentation/serving_data/#running-a-fuseki-server
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-496) TDB Bulk Loader does not record prefixes
[ https://issues.apache.org/jira/browse/JENA-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726624#comment-13726624 ] Hudson commented on JENA-496: - SUCCESS: Integrated in Jena__Development_Test #795 (See [https://builds.apache.org/job/Jena__Development_Test/795/]) Data files for JENA-496 (andy: rev 1509327) * /jena/trunk/jena-tdb/testing/Loader/data-3.trig * /jena/trunk/jena-tdb/testing/Loader/data-4.ttl TDB Bulk Loader does not record prefixes Key: JENA-496 URL: https://issues.apache.org/jira/browse/JENA-496 Project: Apache Jena Issue Type: Bug Components: TDB Affects Versions: Jena 2.10.1 Reporter: Andy Seaborne Assignee: Andy Seaborne The TDB Bulk Loader uses StreamRDF but just skips the prefix declarations. It should record them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-480) Unify HTTP usage and authentication mechanisms in ARQ
[ https://issues.apache.org/jira/browse/JENA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13701017#comment-13701017 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #764 (See [https://builds.apache.org/job/Jena__Development_Test/764/]) Fix bug in FormsAuthenticator caused by spurious toString() call in map lookup (JENA-480) (Revision 1500079) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormsAuthenticator.java * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/util/LocatorURL.java Unify HTTP usage and authentication mechanisms in ARQ - Key: JENA-480 URL: https://issues.apache.org/jira/browse/JENA-480 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.10.2 Original Estimate: 72h Time Spent: 101h Remaining Estimate: 0h Currently ARQ uses a mixture of HttpClient and HttpURLConnection to perform various HTTP operations e.g. SPARQL Queries, SPARQL Updates and SPARQL Graph Store Protocol. This has the effect of making the code somewhat awkward to maintain and makes certain operations like authentication more complex than they need to be because different parts of the system support different modes of authentication. For example currently SPARQL queries only support Basic Auth and they always pre-authenticate so they cannot do proxy auth or use any other kind of auth method. On the other hand SPARQL updates use HttpClient which is capable of performing Basic, Digest, NTLM, SPNEGO and Kerberos for both normal and proxy auth but is never pre-authenticates. This task proposes unifying all HTTP operations in ARQ to use Apache HttpClient since it is more flexible and introducing a more extensible framework for doing authentication. In terms of HTTP unification we need to convert the following: - HttpQuery should use HttpClient - LocatorURL should use HttpClient In terms of HTTP Authentication my idea is as follows, introduce a new interface HttpAuthenticator which provides an apply(AbstractHttpClient client, URI target) method. All systems that may permit HTTP auth will allow use of an authenticator, providing a generic interface for authenticators will allow us to introduce authenticators for other auth schemes e.g. form based logins. We can also provide authenticators that leverage existing mechanisms e.g. storing credentials in a service context which would be used by default. Existing methods that accept username and password would use simpler authenticators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-483) Improve Javadoc for Fuseki artifact.
[ https://issues.apache.org/jira/browse/JENA-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700066#comment-13700066 ] Hudson commented on JENA-483: - Integrated in Jena__Development_Test #759 (See [https://builds.apache.org/job/Jena__Development_Test/759/]) JENA-483 : Javadoc for Fuseki (Revision 1499743) Result = SUCCESS andy : Files : * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/Fuseki.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/SPARQLServer.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/ServerConfig.java Improve Javadoc for Fuseki artifact. Key: JENA-483 URL: https://issues.apache.org/jira/browse/JENA-483 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 0.2.7 Reporter: Lewis John McGibbney Assignee: Andy Seaborne Fix For: Fuseki 0.2.8 Attachments: JENA-483.patch I am currently using the Fuseki 0.2.7 artifact via it's Java API. It is very unclear what should be going on and how I should be using the API. With help from you guys on list ;), I am going to make it a priority to document as much of the module as I can. I will upload the patch here once I have finished. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-480) Unify HTTP usage and authentication mechanisms in ARQ
[ https://issues.apache.org/jira/browse/JENA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699173#comment-13699173 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #755 (See [https://builds.apache.org/job/Jena__Development_Test/755/]) Add overloads for QueryExecutionFactory.sparqlService() that take HttpAuthenticator (JENA-480) (Revision 1499471) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/query/QueryExecutionFactory.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/http/QueryEngineHTTP.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemote.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemoteForm.java Unify HTTP usage and authentication mechanisms in ARQ - Key: JENA-480 URL: https://issues.apache.org/jira/browse/JENA-480 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.10.2 Original Estimate: 72h Time Spent: 101h Remaining Estimate: 0h Currently ARQ uses a mixture of HttpClient and HttpURLConnection to perform various HTTP operations e.g. SPARQL Queries, SPARQL Updates and SPARQL Graph Store Protocol. This has the effect of making the code somewhat awkward to maintain and makes certain operations like authentication more complex than they need to be because different parts of the system support different modes of authentication. For example currently SPARQL queries only support Basic Auth and they always pre-authenticate so they cannot do proxy auth or use any other kind of auth method. On the other hand SPARQL updates use HttpClient which is capable of performing Basic, Digest, NTLM, SPNEGO and Kerberos for both normal and proxy auth but is never pre-authenticates. This task proposes unifying all HTTP operations in ARQ to use Apache HttpClient since it is more flexible and introducing a more extensible framework for doing authentication. In terms of HTTP unification we need to convert the following: - HttpQuery should use HttpClient - LocatorURL should use HttpClient In terms of HTTP Authentication my idea is as follows, introduce a new interface HttpAuthenticator which provides an apply(AbstractHttpClient client, URI target) method. All systems that may permit HTTP auth will allow use of an authenticator, providing a generic interface for authenticators will allow us to introduce authenticators for other auth schemes e.g. form based logins. We can also provide authenticators that leverage existing mechanisms e.g. storing credentials in a service context which would be used by default. Existing methods that accept username and password would use simpler authenticators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-484) Upgrade Lucene and Solr versions to 4.3.1
[ https://issues.apache.org/jira/browse/JENA-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697712#comment-13697712 ] Hudson commented on JENA-484: - Integrated in Jena__Development_Test #752 (See [https://builds.apache.org/job/Jena__Development_Test/752/]) JENA-484 Update to Lucene/Solr 4.3.1 (Revision 1498894) Result = SUCCESS andy : Files : * /jena/trunk/jena-text/pom.xml * /jena/trunk/jena-text/src/main/java/org/apache/jena/query/text/TextIndexLucene.java * /jena/trunk/jena-text/src/test/java/org/apache/jena/query/text/TextSearchUtil.java Upgrade Lucene and Solr versions to 4.3.1 - Key: JENA-484 URL: https://issues.apache.org/jira/browse/JENA-484 Project: Apache Jena Issue Type: Improvement Components: LARQ Reporter: Lewis John McGibbney Priority: Trivial Fix For: LARQ 2.0.0 Attachments: JENA-484.patch Today I tried to do mvn eclipse:eclipse and my build for some reason stalled on download of lucene-core-4.2.1 deps. This trivial patch updates to 4.3.1 which is pulled fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-480) Unify HTTP usage and authentication mechanisms in ARQ
[ https://issues.apache.org/jira/browse/JENA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697167#comment-13697167 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #748 (See [https://builds.apache.org/job/Jena__Development_Test/748/]) Add authentication support to DatasetGraphAccessorHTTP, start adding some tests for this (JENA-480) (Revision 1498680) Clean up javadoc in HttpOp (JENA-480) (Revision 1498666) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/query/DatasetAccessorFactory.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/web/DatasetGraphAccessorHTTP.java * /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/TestAuth.java * /jena/trunk/jena-text/pom.xml rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java Unify HTTP usage and authentication mechanisms in ARQ - Key: JENA-480 URL: https://issues.apache.org/jira/browse/JENA-480 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.10.2 Original Estimate: 72h Time Spent: 5h Remaining Estimate: 67h Currently ARQ uses a mixture of HttpClient and HttpURLConnection to perform various HTTP operations e.g. SPARQL Queries, SPARQL Updates and SPARQL Graph Store Protocol. This has the effect of making the code somewhat awkward to maintain and makes certain operations like authentication more complex than they need to be because different parts of the system support different modes of authentication. For example currently SPARQL queries only support Basic Auth and they always pre-authenticate so they cannot do proxy auth or use any other kind of auth method. On the other hand SPARQL updates use HttpClient which is capable of performing Basic, Digest, NTLM, SPNEGO and Kerberos for both normal and proxy auth but is never pre-authenticates. This task proposes unifying all HTTP operations in ARQ to use Apache HttpClient since it is more flexible and introducing a more extensible framework for doing authentication. In terms of HTTP unification we need to convert the following: - HttpQuery should use HttpClient - LocatorURL should use HttpClient In terms of HTTP Authentication my idea is as follows, introduce a new interface HttpAuthenticator which provides an apply(AbstractHttpClient client, URI target) method. All systems that may permit HTTP auth will allow use of an authenticator, providing a generic interface for authenticators will allow us to introduce authenticators for other auth schemes e.g. form based logins. We can also provide authenticators that leverage existing mechanisms e.g. storing credentials in a service context which would be used by default. Existing methods that accept username and password would use simpler authenticators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-480) Unify HTTP usage and authentication mechanisms in ARQ
[ https://issues.apache.org/jira/browse/JENA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697344#comment-13697344 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #749 (See [https://builds.apache.org/job/Jena__Development_Test/749/]) Add a delegating authenticator which can be used to map different authenticators to different URIs (JENA-480) (Revision 1498721) Rework scoped authenticators to work more sensibly (JENA-480) Credentials are now scoped to any URI derived from them e.g. credentials for http://example.org also apply to http://example.org/some/path However longest match applies since we work backwards from the requested URI so if credentials for http://example.org/some/path were present they would be used instead Added additional tests to validate these changes (Revision 1498718) Result = FAILURE rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/DelegatingAuthenticator.java rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/AbstractCredentialsAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/AbstractScopedAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormLogin.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormsAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ScopedAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ServiceAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/SimpleAuthenticator.java * /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/TestAuth.java Unify HTTP usage and authentication mechanisms in ARQ - Key: JENA-480 URL: https://issues.apache.org/jira/browse/JENA-480 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.10.2 Original Estimate: 72h Time Spent: 5h Remaining Estimate: 67h Currently ARQ uses a mixture of HttpClient and HttpURLConnection to perform various HTTP operations e.g. SPARQL Queries, SPARQL Updates and SPARQL Graph Store Protocol. This has the effect of making the code somewhat awkward to maintain and makes certain operations like authentication more complex than they need to be because different parts of the system support different modes of authentication. For example currently SPARQL queries only support Basic Auth and they always pre-authenticate so they cannot do proxy auth or use any other kind of auth method. On the other hand SPARQL updates use HttpClient which is capable of performing Basic, Digest, NTLM, SPNEGO and Kerberos for both normal and proxy auth but is never pre-authenticates. This task proposes unifying all HTTP operations in ARQ to use Apache HttpClient since it is more flexible and introducing a more extensible framework for doing authentication. In terms of HTTP unification we need to convert the following: - HttpQuery should use HttpClient - LocatorURL should use HttpClient In terms of HTTP Authentication my idea is as follows, introduce a new interface HttpAuthenticator which provides an apply(AbstractHttpClient client, URI target) method. All systems that may permit HTTP auth will allow use of an authenticator, providing a generic interface for authenticators will allow us to introduce authenticators for other auth schemes e.g. form based logins. We can also provide authenticators that leverage existing mechanisms e.g. storing credentials in a service context which would be used by default. Existing methods that accept username and password would use simpler authenticators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-480) Unify HTTP usage and authentication mechanisms in ARQ
[ https://issues.apache.org/jira/browse/JENA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695644#comment-13695644 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #737 (See [https://builds.apache.org/job/Jena__Development_Test/737/]) Allow PreemptiveBasicAuthenticator to do preemptive standard/proxy auth as required (JENA-480) Fix up other log4j properties files to include Apache HTTP settings (Revision 1497861) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/log4j.properties * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/PreemptiveBasicAuthenticator.java * /jena/trunk/jena-arq/src/test/resources/log4j-testing.properties * /jena/trunk/jena-arq/src/test/resources/log4j.properties Unify HTTP usage and authentication mechanisms in ARQ - Key: JENA-480 URL: https://issues.apache.org/jira/browse/JENA-480 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.10.2 Original Estimate: 72h Time Spent: 5h Remaining Estimate: 67h Currently ARQ uses a mixture of HttpClient and HttpURLConnection to perform various HTTP operations e.g. SPARQL Queries, SPARQL Updates and SPARQL Graph Store Protocol. This has the effect of making the code somewhat awkward to maintain and makes certain operations like authentication more complex than they need to be because different parts of the system support different modes of authentication. For example currently SPARQL queries only support Basic Auth and they always pre-authenticate so they cannot do proxy auth or use any other kind of auth method. On the other hand SPARQL updates use HttpClient which is capable of performing Basic, Digest, NTLM, SPNEGO and Kerberos for both normal and proxy auth but is never pre-authenticates. This task proposes unifying all HTTP operations in ARQ to use Apache HttpClient since it is more flexible and introducing a more extensible framework for doing authentication. In terms of HTTP unification we need to convert the following: - HttpQuery should use HttpClient - LocatorURL should use HttpClient In terms of HTTP Authentication my idea is as follows, introduce a new interface HttpAuthenticator which provides an apply(AbstractHttpClient client, URI target) method. All systems that may permit HTTP auth will allow use of an authenticator, providing a generic interface for authenticators will allow us to introduce authenticators for other auth schemes e.g. form based logins. We can also provide authenticators that leverage existing mechanisms e.g. storing credentials in a service context which would be used by default. Existing methods that accept username and password would use simpler authenticators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-480) Unify HTTP usage and authentication mechanisms in ARQ
[ https://issues.apache.org/jira/browse/JENA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695935#comment-13695935 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #738 (See [https://builds.apache.org/job/Jena__Development_Test/738/]) Ensure FormsAuthenticator frees up the connection used for the login (JENA-480) (Revision 1497957) Result = FAILURE rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/FormsAuthenticator.java Unify HTTP usage and authentication mechanisms in ARQ - Key: JENA-480 URL: https://issues.apache.org/jira/browse/JENA-480 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.10.2 Original Estimate: 72h Time Spent: 5h Remaining Estimate: 67h Currently ARQ uses a mixture of HttpClient and HttpURLConnection to perform various HTTP operations e.g. SPARQL Queries, SPARQL Updates and SPARQL Graph Store Protocol. This has the effect of making the code somewhat awkward to maintain and makes certain operations like authentication more complex than they need to be because different parts of the system support different modes of authentication. For example currently SPARQL queries only support Basic Auth and they always pre-authenticate so they cannot do proxy auth or use any other kind of auth method. On the other hand SPARQL updates use HttpClient which is capable of performing Basic, Digest, NTLM, SPNEGO and Kerberos for both normal and proxy auth but is never pre-authenticates. This task proposes unifying all HTTP operations in ARQ to use Apache HttpClient since it is more flexible and introducing a more extensible framework for doing authentication. In terms of HTTP unification we need to convert the following: - HttpQuery should use HttpClient - LocatorURL should use HttpClient In terms of HTTP Authentication my idea is as follows, introduce a new interface HttpAuthenticator which provides an apply(AbstractHttpClient client, URI target) method. All systems that may permit HTTP auth will allow use of an authenticator, providing a generic interface for authenticators will allow us to introduce authenticators for other auth schemes e.g. form based logins. We can also provide authenticators that leverage existing mechanisms e.g. storing credentials in a service context which would be used by default. Existing methods that accept username and password would use simpler authenticators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-480) Unify HTTP usage and authentication mechanisms in ARQ
[ https://issues.apache.org/jira/browse/JENA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13694980#comment-13694980 ] Hudson commented on JENA-480: - Integrated in Jena__Development_Test #729 (See [https://builds.apache.org/job/Jena__Development_Test/729/]) Update authenticaiton for SPARQL Updates to use new authentication framework (JENA-480) (Revision 1497512) Heavily refactored HttpOp to use the new authentication framework (JENA-480) Note that existing API methods are retained for backwards compatibility (Revision 1497510) Unified and extensible authentication framework for Atlas (JENA-480) (Revision 1497509) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemote.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemoteBase.java * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateProcessRemoteForm.java rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/HttpException.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/AbstractCredentialsAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/AbstractScopedAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/HttpAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/PreemptiveBasicAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ScopedAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/ServiceAuthenticator.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/web/auth/SimpleAuthenticator.java Unify HTTP usage and authentication mechanisms in ARQ - Key: JENA-480 URL: https://issues.apache.org/jira/browse/JENA-480 Project: Apache Jena Issue Type: Improvement Components: ARQ Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.10.2 Original Estimate: 72h Time Spent: 5h Remaining Estimate: 67h Currently ARQ uses a mixture of HttpClient and HttpURLConnection to perform various HTTP operations e.g. SPARQL Queries, SPARQL Updates and SPARQL Graph Store Protocol. This has the effect of making the code somewhat awkward to maintain and makes certain operations like authentication more complex than they need to be because different parts of the system support different modes of authentication. For example currently SPARQL queries only support Basic Auth and they always pre-authenticate so they cannot do proxy auth or use any other kind of auth method. On the other hand SPARQL updates use HttpClient which is capable of performing Basic, Digest, NTLM, SPNEGO and Kerberos for both normal and proxy auth but is never pre-authenticates. This task proposes unifying all HTTP operations in ARQ to use Apache HttpClient since it is more flexible and introducing a more extensible framework for doing authentication. In terms of HTTP unification we need to convert the following: - HttpQuery should use HttpClient - LocatorURL should use HttpClient In terms of HTTP Authentication my idea is as follows, introduce a new interface HttpAuthenticator which provides an apply(AbstractHttpClient client, URI target) method. All systems that may permit HTTP auth will allow use of an authenticator, providing a generic interface for authenticators will allow us to introduce authenticators for other auth schemes e.g. form based logins. We can also provide authenticators that leverage existing mechanisms e.g. storing credentials in a service context which would be used by default. Existing methods that accept username and password would use simpler authenticators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-479) Serialization of update requests isn't legal syntax
[
https://issues.apache.org/jira/browse/JENA-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13694109#comment-13694109
]
Hudson commented on JENA-479:
-
Integrated in Jena__Development_Test #724 (See
[https://builds.apache.org/job/Jena__Development_Test/724/])
JENA-479: Use the right kind of bnode mapping for updates. ?? variables
are bnodes. (Revision 1497014)
Result = SUCCESS
andy :
Files :
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/request/UpdateClear.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/request/UpdateWriter.java
Serialization of update requests isn't legal syntax
---
Key: JENA-479
URL: https://issues.apache.org/jira/browse/JENA-479
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Reporter: Elli Schwarz
Assignee: Andy Seaborne
Running the following code:
String updateString = INSERT {} WHERE { ?x ?p [ ?a ?b ] };
UpdateRequest update = UpdateFactory.create(updateString);
UpdateProcessor up = UpdateExecutionFactory.createRemote(update,
http://localhost:3131/ds/update;);
up.execute();
Causes the Fuseki server to throw this error: 400 Encountered ? ?
This is caused by the client generating incorrect SPARQL with an extra ? (as
viewed from the Fuseki log): INSERT { } WHERE { ?x ?p ??0 . ??0 ?a ?b }
This bug may be similar to JENA-378.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-477) Setting the default union graph for a TDB dataset does not work with text search.
[ https://issues.apache.org/jira/browse/JENA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693084#comment-13693084 ] Hudson commented on JENA-477: - Integrated in Jena__Development_Test #718 (See [https://builds.apache.org/job/Jena__Development_Test/718/]) JENA-477 : Fixing working with TDB, esp default union graph. Add tests to pin down expected functionality. (Revision 1496497) Result = SUCCESS andy : Files : * /jena/trunk/jena-text/src/main/java/org/apache/jena/query/text/EntityDefinition.java * /jena/trunk/jena-text/src/main/java/org/apache/jena/query/text/QueryPF.java * /jena/trunk/jena-text/src/main/java/org/apache/jena/query/text/TextDatasetFactory.java * /jena/trunk/jena-text/src/main/java/org/apache/jena/query/text/TextIndexLucene.java * /jena/trunk/jena-text/src/main/java/org/apache/jena/query/text/TextQuery.java * /jena/trunk/jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java * /jena/trunk/jena-text/src/test/java/org/apache/jena/query/text/EMBEDDED_SOLR.java * /jena/trunk/jena-text/src/test/java/org/apache/jena/query/text/EmbeddedSolr.java * /jena/trunk/jena-text/src/test/java/org/apache/jena/query/text/TS_Text.java * /jena/trunk/jena-text/src/test/java/org/apache/jena/query/text/TestBuildTextDataset.java * /jena/trunk/jena-text/src/test/java/org/apache/jena/query/text/TestDatasetWithEmbeddedSolrTextIndex.java * /jena/trunk/jena-text/src/test/java/org/apache/jena/query/text/TestTextTDB.java * /jena/trunk/jena-text/testing/TextQuery/data1.ttl * /jena/trunk/jena-text/testing/TextQuery/text-config-union.ttl * /jena/trunk/jena-text/testing/TextQuery/text-config.ttl Setting the default union graph for a TDB dataset does not work with text search. - Key: JENA-477 URL: https://issues.apache.org/jira/browse/JENA-477 Project: Apache Jena Issue Type: Bug Reporter: Andy Seaborne Assignee: Andy Seaborne If a text dataset is constructed (assembler or code) and then a SPARQL query executes over that, the query engine factory chosen is the general one and not the TDB specific one; the result is that union default graph isn't performed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-473) ARQ should be able to optimize implicit joins and implicit left joins
[
https://issues.apache.org/jira/browse/JENA-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693342#comment-13693342
]
Hudson commented on JENA-473:
-
Integrated in Jena__Development_Test #720 (See
[https://builds.apache.org/job/Jena__Development_Test/720/])
Some code cleanup and TODO comments, update Release Notes (JENA-473)
(Revision 1496611)
Result = SUCCESS
rvesse :
Files :
* /jena/trunk/jena-arq/ReleaseNotes.txt
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformFilterEquality.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformFilterImplicitJoin.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformImplicitLeftJoin.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilters.java
ARQ should be able to optimize implicit joins and implicit left joins
-
Key: JENA-473
URL: https://issues.apache.org/jira/browse/JENA-473
Project: Apache Jena
Issue Type: Improvement
Components: ARQ
Reporter: Rob Vesse
Assignee: Rob Vesse
Labels: optimization, sparql
Fix For: Jena 2.10.2
Attachments: impl-join.csv, impl-join-opt.csv,
impl-join-opt-linearized.csv
There is a class of useful optimizations that currently ARQ does not even
attempt to apply which are usually referred to as implicit joins.
A trivial example is as follows:
SELECT *
WHERE
{
?x ?p1 ?o1 .
?y ?p2 ?o2 .
FILTER(?x = ?y)
}
Currently this requires us to compute a cross product and then apply the
filter, even with streaming evaluation this can be extremely costly. The aim
of this optimization is to produce a query like the following:
SELECT *
WHERE
{
?x ?p1 ?o1 .
?x ?p2 ?o2 .
BIND(?x AS ?y)
}
This optimization can also be applied to some left joins where the implicit
join applies across the join e.g.
SELECT *
WHERE
{
?x ?p1 ?o1 .
OPTIONAL
{
?y ?p2 ?o2 .
FILTER(?x = ?y)
}
}
This can be thought of as a generalization of TransformFilterEquality except
covering the case where both items are variables. Since both things are
variables we need to be careful about when we apply this optimization since
when = is used we need to guarantee that substituting one variable for the
other does not alter the semantics of the query.
I believe the optimization is safe to apply providing that we can guarantee
(as far as possible) that one variable is non-literal. This can be done by
inspecting the positions in which the mentioned variables are used and
ensuring that at least one of the variables occurs in the graph, subject or
predicate position.
Safety for left joins is a little more complex since we must ensure that at
least one of the variables occurs in the RHS and we can only make the
substitution in the RHS as otherwise we change the join semantics.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-475) HTTP Authentication for SPARQL Updates does not actually apply authentication
[ https://issues.apache.org/jira/browse/JENA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693553#comment-13693553 ] Hudson commented on JENA-475: - Integrated in Jena__Development_Test #721 (See [https://builds.apache.org/job/Jena__Development_Test/721/]) Add support for a --basic-auth argument in Fuseki that can be used to have basic auth configured using a Jetty realm file in lieu of a full blown Jetty config. It configures a single role fuseki to which users must belong in order to access any services on the server. If --jetty-config is used the --basic-auth argument is ignored. With this functionality in place added unit tests that verify JENA-475 (Revision 1496676) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-fuseki/pom.xml * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/FusekiCmd.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/SPARQLServer.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/ServerConfig.java * /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/ServerTest.java * /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/TS_Fuseki.java * /jena/trunk/jena-fuseki/src/test/java/org/apache/jena/fuseki/TestAuth.java HTTP Authentication for SPARQL Updates does not actually apply authentication - Key: JENA-475 URL: https://issues.apache.org/jira/browse/JENA-475 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.10.2 A user spotted an error in the logic for applying authentication credentials to SPARQL Updates. It turns out while we create a CredentialsProvider we fail to associate that with the HTTP Client and so fail to actually peform authentication -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-473) ARQ should be able to optimize implicit joins and implicit left joins
[
https://issues.apache.org/jira/browse/JENA-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692485#comment-13692485
]
Hudson commented on JENA-473:
-
Integrated in Jena__Development_Test #717 (See
[https://builds.apache.org/job/Jena__Development_Test/717/])
Improve intelligence of the implicit left join optimization (JENA-473)
The optimizer is now capable of pulling out both sides of an if both are
implicit join conditions and it can make valid substitutions
i.e. the conditions don't overlap in such a way as to block the optimization
It is also now capable of going one level further into when appropriate to
do so (Revision 1496242)
Result = SUCCESS
rvesse :
Files :
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformImplicitLeftJoin.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/function/user/UserDefinedFunctionFactory.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilters.java
ARQ should be able to optimize implicit joins and implicit left joins
-
Key: JENA-473
URL: https://issues.apache.org/jira/browse/JENA-473
Project: Apache Jena
Issue Type: Improvement
Components: ARQ
Reporter: Rob Vesse
Assignee: Rob Vesse
Labels: optimization, sparql
Fix For: Jena 2.10.2
Attachments: impl-join.csv, impl-join-opt.csv,
impl-join-opt-linearized.csv
There is a class of useful optimizations that currently ARQ does not even
attempt to apply which are usually referred to as implicit joins.
A trivial example is as follows:
SELECT *
WHERE
{
?x ?p1 ?o1 .
?y ?p2 ?o2 .
FILTER(?x = ?y)
}
Currently this requires us to compute a cross product and then apply the
filter, even with streaming evaluation this can be extremely costly. The aim
of this optimization is to produce a query like the following:
SELECT *
WHERE
{
?x ?p1 ?o1 .
?x ?p2 ?o2 .
BIND(?x AS ?y)
}
This optimization can also be applied to some left joins where the implicit
join applies across the join e.g.
SELECT *
WHERE
{
?x ?p1 ?o1 .
OPTIONAL
{
?y ?p2 ?o2 .
FILTER(?x = ?y)
}
}
This can be thought of as a generalization of TransformFilterEquality except
covering the case where both items are variables. Since both things are
variables we need to be careful about when we apply this optimization since
when = is used we need to guarantee that substituting one variable for the
other does not alter the semantics of the query.
I believe the optimization is safe to apply providing that we can guarantee
(as far as possible) that one variable is non-literal. This can be done by
inspecting the positions in which the mentioned variables are used and
ensuring that at least one of the variables occurs in the graph, subject or
predicate position.
Safety for left joins is a little more complex since we must ensure that at
least one of the variables occurs in the RHS and we can only make the
substitution in the RHS as otherwise we change the join semantics.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-475) HTTP Authentication for SPARQL Updates does not actually apply authentication
[ https://issues.apache.org/jira/browse/JENA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13690460#comment-13690460 ] Hudson commented on JENA-475: - Integrated in Jena__Development_Test #705 (See [https://builds.apache.org/job/Jena__Development_Test/705/]) SPARQL Updates created a credentials provider but failed to associate it with the HTTP Client so authentication was not performed (JENA-475) (Revision 1495492) Result = SUCCESS rvesse : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/web/HttpOp.java HTTP Authentication for SPARQL Updates does not actually apply authentication - Key: JENA-475 URL: https://issues.apache.org/jira/browse/JENA-475 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Reporter: Rob Vesse Assignee: Rob Vesse Fix For: Jena 2.10.2 A user spotted an error in the logic for applying authentication credentials to SPARQL Updates. It turns out while we create a CredentialsProvider we fail to associate that with the HTTP Client and so fail to actually peform authentication -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-473) ARQ should be able to optimize implicit joins and implicit left joins
[
https://issues.apache.org/jira/browse/JENA-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689760#comment-13689760
]
Hudson commented on JENA-473:
-
Integrated in Jena__Development_Test #698 (See
[https://builds.apache.org/job/Jena__Development_Test/698/])
Initial implementation of implicit join and implicit left join optimizers
(JENA-473)
While there are some test cases for these the test coverage is not yet great
and experimentation has shown that there
are some kinks to be worked out. Currently these optimizations are only used
if explicitly enabled
i.e. they use context.isTrue() rather than context.isTrueOrUndef() to determine
whether they should be applied (Revision 1495205)
Result = SUCCESS
rvesse :
Files :
* /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/query/ARQ.java
* /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/OpVars.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/Optimize.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformFilterImplicitJoin.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformImplicitLeftJoin.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/TS_Algebra.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestSemanticEquivalence.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilters.java
ARQ should be able to optimize implicit joins and implicit left joins
-
Key: JENA-473
URL: https://issues.apache.org/jira/browse/JENA-473
Project: Apache Jena
Issue Type: Improvement
Components: ARQ
Reporter: Rob Vesse
Assignee: Rob Vesse
Labels: optimization, sparql
Fix For: Jena 2.10.2
Attachments: impl-join.csv, impl-join-opt.csv
There is a class of useful optimizations that currently ARQ does not even
attempt to apply which are usually referred to as implicit joins.
A trivial example is as follows:
SELECT *
WHERE
{
?x ?p1 ?o1 .
?y ?p2 ?o2 .
FILTER(?x = ?y)
}
Currently this requires us to compute a cross product and then apply the
filter, even with streaming evaluation this can be extremely costly. The aim
of this optimization is to produce a query like the following:
SELECT *
WHERE
{
?x ?p1 ?o1 .
?x ?p2 ?o2 .
BIND(?x AS ?y)
}
This optimization can also be applied to some left joins where the implicit
join applies across the join e.g.
SELECT *
WHERE
{
?x ?p1 ?o1 .
OPTIONAL
{
?y ?p2 ?o2 .
FILTER(?x = ?y)
}
}
This can be thought of as a generalization of TransformFilterEquality except
covering the case where both items are variables. Since both things are
variables we need to be careful about when we apply this optimization since
when = is used we need to guarantee that substituting one variable for the
other does not alter the semantics of the query.
I believe the optimization is safe to apply providing that we can guarantee
(as far as possible) that one variable is non-literal. This can be done by
inspecting the positions in which the mentioned variables are used and
ensuring that at least one of the variables occurs in the graph, subject or
predicate position.
Safety for left joins is a little more complex since we must ensure that at
least one of the variables occurs in the RHS and we can only make the
substitution in the RHS as otherwise we change the join semantics.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-473) ARQ should be able to optimize implicit joins and implicit left joins
[
https://issues.apache.org/jira/browse/JENA-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689899#comment-13689899
]
Hudson commented on JENA-473:
-
Integrated in Jena__Development_Test #699 (See
[https://builds.apache.org/job/Jena__Development_Test/699/])
Further work on implicit left join optimization (JENA-473)
This commit relaxes the lineraization restriction on left join linearization to
allow linearizing across assignments provided that
all variables used to compute the assignment are themselves defined on the RHS
Includes new tests for optimization and for join classification (Revision
1495240)
Result = FAILURE
rvesse :
Files :
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/main/JoinClassifier.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/main/LeftJoinClassifier.java
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/engine/main/VarFinder.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/TestClassify.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestSemanticEquivalence.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilters.java
ARQ should be able to optimize implicit joins and implicit left joins
-
Key: JENA-473
URL: https://issues.apache.org/jira/browse/JENA-473
Project: Apache Jena
Issue Type: Improvement
Components: ARQ
Reporter: Rob Vesse
Assignee: Rob Vesse
Labels: optimization, sparql
Fix For: Jena 2.10.2
Attachments: impl-join.csv, impl-join-opt.csv,
impl-join-opt-linearized.csv
There is a class of useful optimizations that currently ARQ does not even
attempt to apply which are usually referred to as implicit joins.
A trivial example is as follows:
SELECT *
WHERE
{
?x ?p1 ?o1 .
?y ?p2 ?o2 .
FILTER(?x = ?y)
}
Currently this requires us to compute a cross product and then apply the
filter, even with streaming evaluation this can be extremely costly. The aim
of this optimization is to produce a query like the following:
SELECT *
WHERE
{
?x ?p1 ?o1 .
?x ?p2 ?o2 .
BIND(?x AS ?y)
}
This optimization can also be applied to some left joins where the implicit
join applies across the join e.g.
SELECT *
WHERE
{
?x ?p1 ?o1 .
OPTIONAL
{
?y ?p2 ?o2 .
FILTER(?x = ?y)
}
}
This can be thought of as a generalization of TransformFilterEquality except
covering the case where both items are variables. Since both things are
variables we need to be careful about when we apply this optimization since
when = is used we need to guarantee that substituting one variable for the
other does not alter the semantics of the query.
I believe the optimization is safe to apply providing that we can guarantee
(as far as possible) that one variable is non-literal. This can be done by
inspecting the positions in which the mentioned variables are used and
ensuring that at least one of the variables occurs in the graph, subject or
predicate position.
Safety for left joins is a little more complex since we must ensure that at
least one of the variables occurs in the RHS and we can only make the
substitution in the RHS as otherwise we change the join semantics.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-471) Regression in Algebra.toQuadForm() for nested sub-query with GRAPH clause
[
https://issues.apache.org/jira/browse/JENA-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685691#comment-13685691
]
Hudson commented on JENA-471:
-
Integrated in Jena__Development_Test #694 (See
[https://builds.apache.org/job/Jena__Development_Test/694/])
Remove @Ignore from test case now Andy has fixed JENA-471 (Revision 1493834)
Result = SUCCESS
rvesse :
Files :
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/TestTransformQuads.java
Regression in Algebra.toQuadForm() for nested sub-query with GRAPH clause
-
Key: JENA-471
URL: https://issues.apache.org/jira/browse/JENA-471
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 2.10.1
Reporter: Rob Vesse
Assignee: Andy Seaborne
Fix For: Jena 2.10.2
Our internal testing has flagged up a regression in behaviour between 2.10.0
and 2.10.1 with regards to Algebra.toQuadForm() when applied to sub-queries
nested within a GRAPH clause
The query in question is as follows:
{noformat}
SELECT ?x
WHERE
{ GRAPH ?g
{ { SELECT ?x
WHERE
{ ?x ?p ?g }
}
}
}
{noformat}
With 2.10.0 this produced the following algebra:
{noformat}
(project (?x)
(project (?x)
(quadpattern (quad ?g ?x ?p ?g
{noformat}
With 2.10.1 this now produces an exception:
{noformat}
com.hp.hpl.jena.sparql.ARQInternalErrorException
at
com.hp.hpl.jena.sparql.algebra.OpVars$OpVarsPattern.visit(OpVars.java:197)
at com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:86)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:154)
at com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:43)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:33)
at com.hp.hpl.jena.sparql.algebra.OpVars.mentionedVars(OpVars.java:70)
at com.hp.hpl.jena.sparql.algebra.OpVars.mentionedVars(OpVars.java:62)
at
com.hp.hpl.jena.sparql.algebra.AlgebraQuad$Pusher.visit(AlgebraQuad.java:93)
at com.hp.hpl.jena.sparql.algebra.op.OpGraph.visit(OpGraph.java:46)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.before(OpWalker.java:64)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:84)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:110)
at com.hp.hpl.jena.sparql.algebra.op.OpGraph.visit(OpGraph.java:46)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:85)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:154)
at com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:43)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:38)
at
com.hp.hpl.jena.sparql.algebra.Transformer.applyTransformation(Transformer.java:156)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:149)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:138)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:132)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transform(Transformer.java:57)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformSkipService(Transformer.java:87)
at
com.hp.hpl.jena.sparql.algebra.AlgebraQuad.quadize(AlgebraQuad.java:56)
at com.hp.hpl.jena.sparql.algebra.Algebra.toQuadForm(Algebra.java:89)
{noformat}
I assume this regression happens because of the change to AlgebraQuad to use
OpVars.mentionedVars() in the 2.10.1 dev cycle
While the 2.10.0 algebra may have actually been incorrect it didn't throw a
stack trace and I assume it is possible to make a valid quad transform on
this algebra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-471) Regression in Algebra.toQuadForm() for nested sub-query with GRAPH clause
[
https://issues.apache.org/jira/browse/JENA-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684132#comment-13684132
]
Hudson commented on JENA-471:
-
Integrated in Jena__Development_Test #691 (See
[https://builds.apache.org/job/Jena__Development_Test/691/])
Fix for Jena-471 (Revision 1493336)
Result = SUCCESS
Regression in Algebra.toQuadForm() for nested sub-query with GRAPH clause
-
Key: JENA-471
URL: https://issues.apache.org/jira/browse/JENA-471
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 2.10.1
Reporter: Rob Vesse
Assignee: Andy Seaborne
Fix For: Jena 2.10.2
Our internal testing has flagged up a regression in behaviour between 2.10.0
and 2.10.1 with regards to Algebra.toQuadForm() when applied to sub-queries
nested within a GRAPH clause
The query in question is as follows:
{noformat}
SELECT ?x
WHERE
{ GRAPH ?g
{ { SELECT ?x
WHERE
{ ?x ?p ?g }
}
}
}
{noformat}
With 2.10.0 this produced the following algebra:
{noformat}
(project (?x)
(project (?x)
(quadpattern (quad ?g ?x ?p ?g
{noformat}
With 2.10.1 this now produces an exception:
{noformat}
com.hp.hpl.jena.sparql.ARQInternalErrorException
at
com.hp.hpl.jena.sparql.algebra.OpVars$OpVarsPattern.visit(OpVars.java:197)
at com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:86)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:154)
at com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:43)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:33)
at com.hp.hpl.jena.sparql.algebra.OpVars.mentionedVars(OpVars.java:70)
at com.hp.hpl.jena.sparql.algebra.OpVars.mentionedVars(OpVars.java:62)
at
com.hp.hpl.jena.sparql.algebra.AlgebraQuad$Pusher.visit(AlgebraQuad.java:93)
at com.hp.hpl.jena.sparql.algebra.op.OpGraph.visit(OpGraph.java:46)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.before(OpWalker.java:64)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:84)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:110)
at com.hp.hpl.jena.sparql.algebra.op.OpGraph.visit(OpGraph.java:46)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:85)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:154)
at com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:43)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:38)
at
com.hp.hpl.jena.sparql.algebra.Transformer.applyTransformation(Transformer.java:156)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:149)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:138)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:132)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transform(Transformer.java:57)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformSkipService(Transformer.java:87)
at
com.hp.hpl.jena.sparql.algebra.AlgebraQuad.quadize(AlgebraQuad.java:56)
at com.hp.hpl.jena.sparql.algebra.Algebra.toQuadForm(Algebra.java:89)
{noformat}
I assume this regression happens because of the change to AlgebraQuad to use
OpVars.mentionedVars() in the 2.10.1 dev cycle
While the 2.10.0 algebra may have actually been incorrect it didn't throw a
stack trace and I assume it is possible to make a valid quad transform on
this algebra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-470) Optimizer misses optimization when there are multiple filter possibilities.
[
https://issues.apache.org/jira/browse/JENA-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682235#comment-13682235
]
Hudson commented on JENA-470:
-
Integrated in Jena__Development_Test #685 (See
[https://builds.apache.org/job/Jena__Development_Test/685/])
JENA-470 : Process mixture of disjunctions and other filter expressions.
(Revision 1492649)
Result = UNSTABLE
andy :
Files :
*
/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/algebra/optimize/TransformFilterDisjunction.java
*
/jena/trunk/jena-arq/src/test/java/com/hp/hpl/jena/sparql/algebra/optimize/TestTransformFilters.java
Optimizer misses optimization when there are multiple filter possibilities.
---
Key: JENA-470
URL: https://issues.apache.org/jira/browse/JENA-470
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 2.10.1
Reporter: Andy Seaborne
Assignee: Andy Seaborne
{noformat}
public static void main(String[] args) {
String qs= StrUtils.strjoinNL(PREFIX : http://example/,
SELECT * {,
?s p ?o . ?s q ?v . ,
FILTER (?o = uri1 || ?o = ?uri2
),
// FILTER (?o = uri1 ),
FILTER (?v 5),
} );
Query query = QueryFactory.create(qs) ;
//Query query = QueryFactory.read(Q.rq) ;
System.out.println(query) ;
Op op1 = Algebra.compile(query) ;
Op op2 = Algebra.optimize(op1) ;
System.out.println(op1) ;
System.out.println(op2) ;
}
{noformat}
This query does not have the disjunction/equality optimization applied.
The simple equality FILTER case does get it applied.
The (?v5) is causing the block.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-468) NullPointerException when calling getRDFType()
[
https://issues.apache.org/jira/browse/JENA-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681539#comment-13681539
]
Hudson commented on JENA-468:
-
Integrated in Jena__Development_Test #684 (See
[https://builds.apache.org/job/Jena__Development_Test/684/])
JENA-468 : Protect close of iterator in case an exception happened, leaving
the iterator variable null. (Revision 1492376)
Result = SUCCESS
andy :
Files :
*
/jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/ontology/impl/OntResourceImpl.java
NullPointerException when calling getRDFType()
--
Key: JENA-468
URL: https://issues.apache.org/jira/browse/JENA-468
Project: Apache Jena
Issue Type: Bug
Components: Onotology API
Affects Versions: Jena 2.10.1
Reporter: Sriram Gopalan
Assignee: Andy Seaborne
Fix For: Jena 2.10.2
Attachments: data.ttl
When I run the following code snippet after having loaded the attached ttl
file, I get a NullPointerException @
com.hp.hpl.jena.ontology.impl.OntResourceImpl#getRDFType(boolean direct) -
Line 833
{noformat}
Resource bob = model.getResource(http://example.org/bob;);
OntResource ontBob = bob.as(OntResource.class);
ontBob.getRDFType()
{noformat}
Upon inspection, it appears as though the code is not checking to see if the
iterator is null, before calling the close() method
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-467) IRIResolverNormal should use synchronized CacheLRU
[ https://issues.apache.org/jira/browse/JENA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13677084#comment-13677084 ] Hudson commented on JENA-467: - Integrated in Jena__Development_Test #675 (See [https://builds.apache.org/job/Jena__Development_Test/675/]) JENA-467 - Add synchronization to the use of global resolver when making a new normal resolver. (Revision 1490313) Result = SUCCESS andy : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/lib/cache/CacheLRU.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/system/IRIResolver.java IRIResolverNormal should use synchronized CacheLRU -- Key: JENA-467 URL: https://issues.apache.org/jira/browse/JENA-467 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 2.10.1 Environment: Any IBM JRE 6 or higher Reporter: Simon Helsen Assignee: Andy Seaborne Fix For: Jena 2.10.2 Attachments: iriresolver-patch-2.txt, iriresolver-patch.txt, patch.txt The following exception may occur on an IBM JRE 6 or higher when more than one thread requires access to the org.apache.jena.atlas.lib.cache.CacheLRU embedded in IRIResolverNormal: Caused by: java.lang.NullPointerException at java.util.LinkedHashMap.get(LinkedHashMap.java:337) at org.apache.jena.atlas.lib.cache.CacheLRU.get(CacheLRU.java:53) at org.apache.jena.riot.system.IRIResolver$IRIResolverNormal.resolveSilent(IRIResolver.java:403) at org.apache.jena.riot.system.IRIResolver$IRIResolverNormal.init(IRIResolver.java:359) at org.apache.jena.riot.system.IRIResolver.create(IRIResolver.java:212) at org.apache.jena.riot.system.RiotLib.profile(RiotLib.java:141) at org.apache.jena.riot.system.RiotLib.profile(RiotLib.java:130) at org.apache.jena.riot.system.RiotLib.profile(RiotLib.java:117) at org.apache.jena.riot.RiotReader.createParserTurtle(RiotReader.java:310) at org.apache.jena.riot.RiotReader.createParser(RiotReader.java:142) at org.apache.jena.riot.RiotReader.createParser(RiotReader.java:133) at org.apache.jena.riot.RDFParserRegistry$ReaderRIOTFactoryImpl$1.read(RDFParserRegistry.java:141) at org.apache.jena.riot.RDFDataMgr.process(RDFDataMgr.java:760) at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:258) at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:244) ... 20 more The problem seems to only occurs on IBM JRE 6 or higher as its implementation of LinkedHashMap is not thread safe. Note that the JDK specification does not required LinkedHashMap to be thread safe. The solution is to make use of CacheFactory.createSync when creating the Cache in the IRIResolverNormal. Patch attached -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-464) Errors in the example code supplied with the Jena download
[ https://issues.apache.org/jira/browse/JENA-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673095#comment-13673095 ] Hudson commented on JENA-464: - Integrated in Jena__Development_Test #671 (See [https://builds.apache.org/job/Jena__Development_Test/671/]) JENA-464 : Use strict SPARQL 1.1 syntax for LOAD ... INTO GRAPH ... (Revision 1488979) Result = SUCCESS andy : Files : * /jena/trunk/jena-arq/src-examples/arq/examples/update/UpdateExecuteOperations.java Errors in the example code supplied with the Jena download -- Key: JENA-464 URL: https://issues.apache.org/jira/browse/JENA-464 Project: Apache Jena Issue Type: Bug Components: ARQ, Jena Affects Versions: ARQ 2.9.4, Jena 2.10.1 Environment: I don't think this is relevant, however just in case: Eclipse Juno Service Release 2, Java 1.7, Ubuntu 12.04 64-bit, Jena 2.10.1 Reporter: John Ringland Priority: Trivial Labels: code, error, examples Original Estimate: 0.5h Remaining Estimate: 0.5h Two types of errors in the example code: Error 1: (simple solution given) When trying to run the example code in src-examples/arq/examples/update I got the error message: Exception in thread main com.hp.hpl.jena.query.QueryParseException: Encountered IRIref http://example/g2 at line 1, column 38. Was expecting: graph ... An example of the offending code from UpdateExecuteOperations.java is: UpdateFactory.parse(request, LOAD file:etc/update-data.ttl INTO http://example/g2) ; When I tried changing INTO to INTO GRAPH the examples worked fine. Error 2: (solution unknown) After importing all the src-examples into an eclipse project (properly configured with all the libraries in apache-jena-2.10.1/lib) all the example code compiled except for src-examples/org/apache/jena/example/Base.java Because several examples depend on Base.java those examples cannot be run. In Base.java Eclipse complains that org.apache.commons.cli.* cannot be resolved. Furthermore there are numerous other compile errors throughout that file, which may be related to the missing import. I resolved the error re CommandLine by importing jena.cmdline.CommandLine To resolve the error re ParseException there are multiple possible imports and it is not clear which is required. Regarding the other errors (Options, GnuParser, HelpFormatter) eclipse could not find anything from the Jena libraries to suggest for import. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-464) Errors in the example code supplied with the Jena download
[ https://issues.apache.org/jira/browse/JENA-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673101#comment-13673101 ] Hudson commented on JENA-464: - Integrated in Jena__Development_Test #672 (See [https://builds.apache.org/job/Jena__Development_Test/672/]) JENA-464: Include jena-examples/ whole (Revision 1488982) Result = SUCCESS andy : Files : * /jena/trunk/apache-jena/assembly-jena-zip.xml * /jena/trunk/jena-examples/pom.xml Errors in the example code supplied with the Jena download -- Key: JENA-464 URL: https://issues.apache.org/jira/browse/JENA-464 Project: Apache Jena Issue Type: Bug Components: ARQ, Jena Affects Versions: ARQ 2.9.4, Jena 2.10.1 Environment: I don't think this is relevant, however just in case: Eclipse Juno Service Release 2, Java 1.7, Ubuntu 12.04 64-bit, Jena 2.10.1 Reporter: John Ringland Assignee: Andy Seaborne Priority: Trivial Labels: code, error, examples Fix For: Jena 2.10.2 Original Estimate: 0.5h Remaining Estimate: 0.5h Two types of errors in the example code: Error 1: (simple solution given) When trying to run the example code in src-examples/arq/examples/update I got the error message: Exception in thread main com.hp.hpl.jena.query.QueryParseException: Encountered IRIref http://example/g2 at line 1, column 38. Was expecting: graph ... An example of the offending code from UpdateExecuteOperations.java is: UpdateFactory.parse(request, LOAD file:etc/update-data.ttl INTO http://example/g2) ; When I tried changing INTO to INTO GRAPH the examples worked fine. Error 2: (solution unknown) After importing all the src-examples into an eclipse project (properly configured with all the libraries in apache-jena-2.10.1/lib) all the example code compiled except for src-examples/org/apache/jena/example/Base.java Because several examples depend on Base.java those examples cannot be run. In Base.java Eclipse complains that org.apache.commons.cli.* cannot be resolved. Furthermore there are numerous other compile errors throughout that file, which may be related to the missing import. I resolved the error re CommandLine by importing jena.cmdline.CommandLine To resolve the error re ParseException there are multiple possible imports and it is not clear which is required. Regarding the other errors (Options, GnuParser, HelpFormatter) eclipse could not find anything from the Jena libraries to suggest for import. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-434) Build the Fuseki server executable jar with the shade plugin
[ https://issues.apache.org/jira/browse/JENA-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13672301#comment-13672301 ] Hudson commented on JENA-434: - Integrated in Jena__Development_Test #670 (See [https://builds.apache.org/job/Jena__Development_Test/670/]) JENA-434 : Use shade plugin to build the fuseki server all-in-one jar. (Revision 1488600) Result = SUCCESS andy : Files : * /jena/trunk/jena-fuseki/pom.xml Build the Fuseki server executable jar with the shade plugin Key: JENA-434 URL: https://issues.apache.org/jira/browse/JENA-434 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 0.2.6 Reporter: Andy Seaborne Assignee: Andy Seaborne Priority: Minor Attachments: Jena434-shade-example.txt The assembly plug in can build executable jars but it generated a lot of messages (hard to suppress). Teh shade plugin does a better job, gives more control, and manages licenses. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-427) Statistics for Fuseki usage.
[ https://issues.apache.org/jira/browse/JENA-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670404#comment-13670404 ] Hudson commented on JENA-427: - Integrated in Jena__Development_Test #667 (See [https://builds.apache.org/job/Jena__Development_Test/667/]) JENA-427 Consistent style for counters. Add stats for SPARQL Update. (Revision 1487878) Result = UNSTABLE andy : Files : * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/CounterName.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/SPARQLServer.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/Stats.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Query.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_ServletBase.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Update.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/StatsServlet.java Statistics for Fuseki usage. Key: JENA-427 URL: https://issues.apache.org/jira/browse/JENA-427 Project: Apache Jena Issue Type: Improvement Components: ARQ, Fuseki, TDB Reporter: Andy Seaborne Assignee: Andy Seaborne Labels: mentor Between ARQ and Fuseki, there could be statistics on usage gathered for exposure via JMX. ARQ collects only a basic count. Fuseki could collect per dataset. What statistics would be useful? How would they be JMX-named? Statistics are useful for debugging and for long term system monitorings. Please add suggestions to the JIRA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-463) Make DOT optional after @prefix and @base (Turtle based syntaxes)
[ https://issues.apache.org/jira/browse/JENA-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671167#comment-13671167 ] Hudson commented on JENA-463: - Integrated in Jena__Development_Test #668 (See [https://builds.apache.org/job/Jena__Development_Test/668/]) JENA-463 - Tests (Revision 1488016) JENA-463 - Make DOT optional at end of @prefix and @base (does not affect PREFIX or BASE) (Revision 1488006) Result = SUCCESS andy : Files : * /jena/trunk/jena-arq/src/test/java/org/apache/jena/riot/lang/TestLangTurtle.java andy : Files : * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/LangEngine.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/LangRDFJSON.java * /jena/trunk/jena-arq/src/main/java/org/apache/jena/riot/lang/LangTurtleBase.java Make DOT optional after @prefix and @base (Turtle based syntaxes) - Key: JENA-463 URL: https://issues.apache.org/jira/browse/JENA-463 Project: Apache Jena Issue Type: Improvement Reporter: Andy Seaborne Assignee: Andy Seaborne Either the RDF-WG is going to put that in the grammar Or it just makes one less thing an app developer needs to track when working across SPARQL and Turtle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-267) SPARQL JSON Parser is not streaming
[ https://issues.apache.org/jira/browse/JENA-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671168#comment-13671168 ] Hudson commented on JENA-267: - Integrated in Jena__Development_Test #668 (See [https://builds.apache.org/job/Jena__Development_Test/668/]) Remove deprecations: + use org.apache.jena.riot.ParseException, not org.openjena.riot.RiotParseException; + use NodeFactory, not Node.create* JENA-267 (Revision 1488004) Result = SUCCESS andy : Files : * /jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/resultset/JSONInputIterator.java SPARQL JSON Parser is not streaming --- Key: JENA-267 URL: https://issues.apache.org/jira/browse/JENA-267 Project: Apache Jena Issue Type: Improvement Components: ARQ Affects Versions: ARQ 2.9.1 Reporter: Rob Vesse Assignee: Rob Vesse Labels: json, sparql The current SPARQL JSON parser in ARQ parses the JSON by parsing the entire response into a in-memory data structure and then iterating over that. So for large results it is trivial to hit an OutOfMemory exception. This task is to reimplement the SPARQL JSON parser to be fully streaming in its implementation in line with all the other results parsers -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-427) Statistics for Fuseki usage.
[ https://issues.apache.org/jira/browse/JENA-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669285#comment-13669285 ] Hudson commented on JENA-427: - Integrated in Jena__Development_Test #664 (See [https://builds.apache.org/job/Jena__Development_Test/664/]) JENA-427 : Reorganise counters for operations. (Revision 1487491) Result = FAILURE andy : Files : * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/mgt/ActionBackup.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/Counter.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/CounterName.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/CounterSet.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/DatasetRef.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/FusekiConfig.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/SPARQLServer.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/ServiceRef.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/server/Stats.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/HttpAction.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_Query.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_REST.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_ServletBase.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/SPARQL_UberServlet.java * /jena/trunk/jena-fuseki/src/main/java/org/apache/jena/fuseki/servlets/StatsServlet.java Statistics for Fuseki usage. Key: JENA-427 URL: https://issues.apache.org/jira/browse/JENA-427 Project: Apache Jena Issue Type: Improvement Components: ARQ, Fuseki, TDB Reporter: Andy Seaborne Assignee: Andy Seaborne Labels: mentor Between ARQ and Fuseki, there could be statistics on usage gathered for exposure via JMX. ARQ collects only a basic count. Fuseki could collect per dataset. What statistics would be useful? How would they be JMX-named? Statistics are useful for debugging and for long term system monitorings. Please add suggestions to the JIRA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-458) Make model work across transaction boundaries / make model.begin do something reasonable.
[ https://issues.apache.org/jira/browse/JENA-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659984#comment-13659984 ] Hudson commented on JENA-458: - Integrated in Jena__Development_Test #647 (See [https://builds.apache.org/job/Jena__Development_Test/647/]) Part of JENA-458. Rework GraphTDB so that there is one class for graph views of the database. Use as much of the machinery of ARQ general GraphView system while still carrying around the necessary information for TDB SPARQL evaluation. Graphs are still restricted to be within a transaction boundary. (Revision 1483446) Result = SUCCESS andy : Files : * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/TDBLoader.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/graph/BulkUpdateHandlerTDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/graph/TransactionHandlerTDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/solver/OpExecutorTDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/solver/QueryEngineTDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/solver/SolverLib.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/store/DatasetGraphTDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/store/GraphNamedTDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/store/GraphTDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/store/GraphTDBBase.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/store/GraphTriplesTDB.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/sys/TDBInternal.java * /jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/transaction/DatasetGraphTransaction.java * /jena/trunk/jena-tdb/src/test/java/com/hp/hpl/jena/tdb/assembler/TestTDBAssembler.java * /jena/trunk/jena-tdb/src/test/java/com/hp/hpl/jena/tdb/store/TestDatasetTDB.java Make model work across transaction boundaries / make model.begin do something reasonable. - Key: JENA-458 URL: https://issues.apache.org/jira/browse/JENA-458 Project: Apache Jena Issue Type: Improvement Components: TDB Affects Versions: TDB 0.10.1 Reporter: Andy Seaborne Priority: Minor Currently, the model view must be re-feteched from the TDB dataset across transaction boundaries even if all updates went via the model. For some models, this is expensive - for example, inference models with significant forward chaining. A problem will always be that if the database can change via a different route. A side-effect will be that model.begin()/model.commit()/model.abort() can be implemented as always being a write transaction. It would need an API change to support the difference between read and write. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-450) Creating an OntModel can update the prefixes, causing a DB write.
[ https://issues.apache.org/jira/browse/JENA-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13655337#comment-13655337 ] Hudson commented on JENA-450: - Integrated in Jena__Development_Test #643 (See [https://builds.apache.org/job/Jena__Development_Test/643/]) JENA-450 Protect setting prefixes against exceptions from read-only graphs. (Revision 1481374) Result = SUCCESS andy : Files : * /jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/ontology/impl/OntModelImpl.java Creating an OntModel can update the prefixes, causing a DB write. - Key: JENA-450 URL: https://issues.apache.org/jira/browse/JENA-450 Project: Apache Jena Issue Type: Bug Components: TDB Affects Versions: TDB 0.10.0 Reporter: Andy Seaborne Assignee: Andy Seaborne Fix For: Jena 2.10.1 Attachments: Jena450_OntModelPrefixesWrite.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-442) Improved Fuseki Shellscript
[ https://issues.apache.org/jira/browse/JENA-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13643112#comment-13643112 ] Hudson commented on JENA-442: - Integrated in Jena__Development_Test #630 (See [https://builds.apache.org/job/Jena__Development_Test/630/]) Add JENA-442 to the ReleaseNotes (Revision 1476256) Result = FAILURE andy : Files : * /jena/trunk/jena-fuseki/ReleaseNotes.txt Improved Fuseki Shellscript --- Key: JENA-442 URL: https://issues.apache.org/jira/browse/JENA-442 Project: Apache Jena Issue Type: Improvement Components: Fuseki Environment: Caixa Magica 18 LTS (Ubuntu 12.04 Based Distro) x86_64. Reporter: Luís Duarte Assignee: Stephen Allen Priority: Minor Labels: newbie, patch Fix For: Fuseki 0.2.7 Attachments: JENA-442.patch Original Estimate: 24h Remaining Estimate: 24h Improve fuseki shellscript to support start-stop-daemon, config files and run as another user. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
