[GitHub] jena issue #209: Close writers in NTtriple

2017-02-09 Thread ajs6f
Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/209
  
Perhaps you could open an ordinary Jira issue with sample data and code?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] jena issue #209: Close writers in NTtriple

2017-02-09 Thread rafaelcoutinho
Github user rafaelcoutinho commented on the issue:

https://github.com/apache/jena/pull/209
  
I know there is no query context or model, however one thing that I 
identified is that using different jena versions the executing time changes a 
lot. I don't think it's the query itself but it looks like jena avoids 
processing the entire model until needed, so when the query is executed jena 
seems to be performing the full inferences.

The odd thing is that version 3.0.1 is much faster than newer ones:

- v3.0.1 - takes 100s
- v3.1.1 - takes 222s
- v3.2.0 - takes 220


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] jena pull request #209: Close writers in NTtriple

2017-02-09 Thread rafaelcoutinho
GitHub user rafaelcoutinho reopened a pull request:

https://github.com/apache/jena/pull/209

Close writers in NTtriple

Not sure why writers are not being closed in the Ntriple RDFWriter.

I believe this is a good practice and (still under investigation) I suspect 
this is causing my application to have a memory leak (since I dump all the 
intermediary models on a server application).

Let me know if this is acceptable and i can make the same change on the 
other RDFWriters.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rafaelcoutinho/jena master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/209.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #209


commit 16c1be82aa9e72c4512d6066e6f54248b26c658b
Author: Rafael Coutinho 
Date:   2017-01-30T13:57:59Z

Close writers in NTtriple




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] jena pull request #209: Close writers in NTtriple

2017-02-09 Thread rafaelcoutinho
Github user rafaelcoutinho closed the pull request at:

https://github.com/apache/jena/pull/209


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (JENA-732) Default generation target for schemagen maven plugin needs a dir

2017-02-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on JENA-732:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/37
  
Given that #38 is merged, is this still live?


> Default generation target for schemagen maven plugin needs a dir
> 
>
> Key: JENA-732
> URL: https://issues.apache.org/jira/browse/JENA-732
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Maven Tools
>Affects Versions: Jena 2.11.2
>Reporter: Benson Margulies
>
> target/generated-sources is the root of roots; it typically contains 
> directories that in turn contain directories. Adding a /jena would make 
> sense. Also, making the directory configurable would be nice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] jena issue #37: JENA-732 jena-maven-tools outputs to target/generated-source...

2017-02-09 Thread ajs6f
Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/37
  
Given that #38 is merged, is this still live?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (JENA-909) Create Docker launcher for Fuseki

2017-02-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on JENA-909:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/50
  
@stain @kinow Were we able to get testing of some kind done? I can see real 
utility for a Docker image, because it would let a wider audience try out 
Fuseki more easily, and for some people, would give them a headstart on 
constructing their own Docker setups. (Docker is becoming an increasingly 
popular deployment mechanism.)


> Create Docker launcher for Fuseki
> -
>
> Key: JENA-909
> URL: https://issues.apache.org/jira/browse/JENA-909
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Reporter: Andy Seaborne
>
> Provide a Docker launcher and setup documentation for  Fuseki2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] jena issue #50: JENA-909 - Docker image for Fuseki 2

2017-02-09 Thread ajs6f
Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/50
  
@stain @kinow Were we able to get testing of some kind done? I can see real 
utility for a Docker image, because it would let a wider audience try out 
Fuseki more easily, and for some people, would give them a headstart on 
constructing their own Docker setups. (Docker is becoming an increasingly 
popular deployment mechanism.)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] jena issue #114: JENA-632: Generate JSON from SPARQL directly

2017-02-09 Thread ajs6f
Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/114
  
@kinow is this still live?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (JENA-632) Generate JSON from SPARQL directly.

2017-02-09 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on JENA-632:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/114
  
@kinow is this still live?


> Generate JSON from SPARQL directly.
> ---
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ, Fuseki
>Reporter: Andy Seaborne
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: java, javacc
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL) 
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user 
> community, basic understanding of HTTP and content negotiation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] jena pull request #214: Small changes

2017-02-09 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/214


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (JENA-1277) Spatial Queries Very Slow For Large Databases

2017-02-09 Thread samur araujo (JIRA)

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

samur araujo commented on JENA-1277:


Dear Osma, I did not find the time yet to check it. I will find a time next 
week and report my feedback here. 

Best,

> Spatial Queries Very Slow For Large Databases
> -
>
> Key: JENA-1277
> URL: https://issues.apache.org/jira/browse/JENA-1277
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Spatial
>Affects Versions: Jena 3.1.1
> Environment: Linux Ubuntu
>Reporter: samur araujo
>Assignee: Osma Suominen
> Fix For: Jena 3.2.0
>
> Attachments: spatial-assembler.ttl
>
>
> I loaded geonames on Jena but the spatial queries take more than 3s to 
> execute. The query is below:
> PREFIX spatial: 
> PREFIX rdfs: 
> SELECT distinct ?place
> {
> ?place spatial:intersectBox (32.55668 -117.12865 32.56668  -117.13865) .
>   
> }
> The data can be downloaded here:
> https://drive.google.com/file/d/0B-fwYPJYT1GOYVVIZF9ROUxzclk/view?usp=sharing
> For small datasets the queries are executed in 200ms, very fast. I noticed 
> that when I access the lucene index directly the queries are also very fast, 
> about 20ms. 
> The issue may be related to the pos-processing of lucene results.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] jena pull request #216: JENA-1288: Remove use of Xerces when alternatives ex...

2017-02-09 Thread afs
GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/216

JENA-1288: Remove use of Xerces when alternatives exist.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena clean-xerces

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/216.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #216


commit 3c89e23b8cda5ab4b73141607900d82f72edc075
Author: Andy Seaborne 
Date:   2017-02-09T13:00:58Z

JENA-1288: Remove use of Xerces when alternatives exist.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Resolved] (JENA-1277) Spatial Queries Very Slow For Large Databases

2017-02-09 Thread Osma Suominen (JIRA)

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

Osma Suominen resolved JENA-1277.
-
Resolution: Fixed

Right. I was hoping for the original reporter to confirm the fix, but he hasn't 
responded. I will assume it is fixed so I will close this. As Andy noted, it 
can be reopened if necessary.

> Spatial Queries Very Slow For Large Databases
> -
>
> Key: JENA-1277
> URL: https://issues.apache.org/jira/browse/JENA-1277
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Spatial
>Affects Versions: Jena 3.1.1
> Environment: Linux Ubuntu
>Reporter: samur araujo
>Assignee: Osma Suominen
> Fix For: Jena 3.2.0
>
> Attachments: spatial-assembler.ttl
>
>
> I loaded geonames on Jena but the spatial queries take more than 3s to 
> execute. The query is below:
> PREFIX spatial: 
> PREFIX rdfs: 
> SELECT distinct ?place
> {
> ?place spatial:intersectBox (32.55668 -117.12865 32.56668  -117.13865) .
>   
> }
> The data can be downloaded here:
> https://drive.google.com/file/d/0B-fwYPJYT1GOYVVIZF9ROUxzclk/view?usp=sharing
> For small datasets the queries are executed in 200ms, very fast. I noticed 
> that when I access the lucene index directly the queries are also very fast, 
> about 20ms. 
> The issue may be related to the pos-processing of lucene results.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (JENA-1223) Provide transaction promotion

2017-02-09 Thread Andy Seaborne (JIRA)

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

Andy Seaborne closed JENA-1223.
---
   Resolution: Fixed
Fix Version/s: Jena 3.1.1

> Provide transaction promotion
> -
>
> Key: JENA-1223
> URL: https://issues.apache.org/jira/browse/JENA-1223
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: TDB
>Affects Versions: Jena 3.1.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
> Fix For: Jena 3.1.1
>
>
> This JIRA is to add the ability for a read transaction to promote to a write 
> transaction.
> API changes are necessary to expose this feature properly and uniformly.
> PR #161 provides the machinery for TDB. To avoid general API changes outside 
> TDB, this happens automatically in {{DatasetGraphTransaction.getW()}} if 
> enabled (by default it isn't, the PR makes no change to behaviour of TDB by 
> default).  It needs to be enabled with {{DatasetGraphTransaction.promotion = 
> true}}. PR#161 does contain internal changes (e.g. {{DatasetGraphWrapper}}) 
> outside TDB.
> This leads towards a general {{begin()}} for transactions. 
> This JIRA is cover discussion on the API and record changes to the subsystems.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (JENA-1223) Provide transaction promotion

2017-02-09 Thread Andy Seaborne (JIRA)

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

Andy Seaborne reassigned JENA-1223:
---

Assignee: Andy Seaborne

> Provide transaction promotion
> -
>
> Key: JENA-1223
> URL: https://issues.apache.org/jira/browse/JENA-1223
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: TDB
>Affects Versions: Jena 3.1.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>
> This JIRA is to add the ability for a read transaction to promote to a write 
> transaction.
> API changes are necessary to expose this feature properly and uniformly.
> PR #161 provides the machinery for TDB. To avoid general API changes outside 
> TDB, this happens automatically in {{DatasetGraphTransaction.getW()}} if 
> enabled (by default it isn't, the PR makes no change to behaviour of TDB by 
> default).  It needs to be enabled with {{DatasetGraphTransaction.promotion = 
> true}}. PR#161 does contain internal changes (e.g. {{DatasetGraphWrapper}}) 
> outside TDB.
> This leads towards a general {{begin()}} for transactions. 
> This JIRA is cover discussion on the API and record changes to the subsystems.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (JENA-1277) Spatial Queries Very Slow For Large Databases

2017-02-09 Thread Andy Seaborne (JIRA)

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

Andy Seaborne commented on JENA-1277:
-

This has just be released in Jena 3.2.0 - can we resolve and close this now? 
(it can be reopened later)

> Spatial Queries Very Slow For Large Databases
> -
>
> Key: JENA-1277
> URL: https://issues.apache.org/jira/browse/JENA-1277
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Spatial
>Affects Versions: Jena 3.1.1
> Environment: Linux Ubuntu
>Reporter: samur araujo
>Assignee: Osma Suominen
> Attachments: spatial-assembler.ttl
>
>
> I loaded geonames on Jena but the spatial queries take more than 3s to 
> execute. The query is below:
> PREFIX spatial: 
> PREFIX rdfs: 
> SELECT distinct ?place
> {
> ?place spatial:intersectBox (32.55668 -117.12865 32.56668  -117.13865) .
>   
> }
> The data can be downloaded here:
> https://drive.google.com/file/d/0B-fwYPJYT1GOYVVIZF9ROUxzclk/view?usp=sharing
> For small datasets the queries are executed in 200ms, very fast. I noticed 
> that when I access the lucene index directly the queries are also very fast, 
> about 20ms. 
> The issue may be related to the pos-processing of lucene results.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (JENA-1287) JSON improvements

2017-02-09 Thread Andy Seaborne (JIRA)

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

Andy Seaborne resolved JENA-1287.
-
Resolution: Fixed

> JSON improvements
> -
>
> Key: JENA-1287
> URL: https://issues.apache.org/jira/browse/JENA-1287
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.2.0
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
> Fix For: Jena 3.3.0
>
>
> A number of small improvement to the JSON handling code:
> * Ensure multiline output/strings end in NL
> * Add to pair(,) to JSONBuilder (c.f. JSWriter)
> * Return 'this' for chaining style in JSONBuilder
> * JSON.copy, JSON.buildObject
> PR#215



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (JENA-1285) Have on Tokenizer token for strings.

2017-02-09 Thread Andy Seaborne (JIRA)

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

Andy Seaborne resolved JENA-1285.
-
   Resolution: Fixed
Fix Version/s: Jena 3.3.0

> Have on Tokenizer token for strings.
> 
>
> Key: JENA-1285
> URL: https://issues.apache.org/jira/browse/JENA-1285
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: RIOT
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.3.0
>
>
> The Tokenizer ({{TokenizerText}}) faithfully records what sort of string it 
> has processed using different token types - STRING1, STRING2, LONG_STRING1, 
> LONG_STRING2.
> Sometimes it matters (N-Triples), sometimes it doesn't (Turtle).
> [Turtle rule for 
> strings|https://www.w3.org/TR/turtle/#grammar-production-String]
> [N-Triples rule for 
> strings|https://www.w3.org/TR/n-triples/#grammar-production-STRING_LITERAL_QUOTE]
> Instead of 4 tokens, (5 if you include the existing STRING token) it is 
> proposed to use one token type STRING and record the actual string type seen 
> separately.
> This is make working with non-text formats simpler where there are strings 
> without the concept of quotes, and any format that works with any string form.
> The specific cases (e.g. N-Triples) can still test for the details of the 
> string syntax seen but the token type is the conceptual "superclass" STRING 
> type.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (JENA-1037) jena-osgi

2017-02-09 Thread Andy Seaborne (JIRA)

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

Andy Seaborne updated JENA-1037:

Description: 
I'm trying to create a simple interface/impl that will generate Prov-O RDF and 
place it on a JMS queue.  This object will live in an OSGi environment and be 
injected into various operating services working in a workflow.  I call the 
following piece of code:

{noformat}
public static OntModel createModel(final String ontologyUri) {
final OntModel model = 
ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM);
model.read(ontologyUri);
return model;
}
{noformat}
with the ontologyUri="http://www.w3.org/ns/prov-o;;  but when it gets to the 
ModelFactory.createOntologyModel(...) it chokes with the following stack trace. 
 
{noformat}
java.lang.IncompatibleClassChangeError: Class 
org.apache.jena.rdfxml.xmlinput.impl.RDFXMLParser$SAXParserWithEncodingCheck 
does not implement the requested interface org.xml.sax.XMLReader
at org.apache.jena.rdfxml.xmlinput.SAX2RDF.installHandlers(SAX2RDF.java:171)
at 
org.apache.jena.rdfxml.xmlinput.impl.RDFXMLParser.(RDFXMLParser.java:63)
at 
org.apache.jena.rdfxml.xmlinput.impl.RDFXMLParser.create(RDFXMLParser.java:127)
at org.apache.jena.rdfxml.xmlinput.JenaReader.(JenaReader.java:69)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
Method)[:1.8.0_11]
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)[:1.8.0_11]
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.8.0_11]
at 
java.lang.reflect.Constructor.newInstance(Constructor.java:408)[:1.8.0_11]
at java.lang.Class.newInstance(Class.java:433)[:1.8.0_11]
at 
org.apache.jena.rdf.model.impl.RDFReaderFImpl.getReader(RDFReaderFImpl.java:120)
at org.apache.jena.rdf.model.impl.ModelCom.read(ModelCom.java:279)
at 
org.apache.jena.ontology.OntDocumentManager.findMetadata(OntDocumentManager.java:892)
at 
org.apache.jena.ontology.OntDocumentManager.initialiseMetadata(OntDocumentManager.java:850)
at 
org.apache.jena.ontology.OntDocumentManager.(OntDocumentManager.java:198)
at 
org.apache.jena.ontology.OntDocumentManager.(OntDocumentManager.java:180)
at 
org.apache.jena.ontology.OntDocumentManager.(OntDocumentManager.java:164)
at 
org.apache.jena.ontology.OntDocumentManager.getInstance(OntDocumentManager.java:242)
at 
org.apache.jena.ontology.OntModelSpec.getDocumentManager(OntModelSpec.java:320)
at 
org.apache.jena.ontology.impl.OntModelImpl.getDocumentManager(OntModelImpl.java:189)
at 
org.apache.jena.ontology.impl.OntModelImpl.loadImports(OntModelImpl.java:1964)
at org.apache.jena.ontology.impl.OntModelImpl.(OntModelImpl.java:151)
at org.apache.jena.ontology.impl.OntModelImpl.(OntModelImpl.java:131)
at 
org.apache.jena.rdf.model.ModelFactory.createOntologyModel(ModelFactory.java:288)
... 
{noformat}
What's triggering this exception is the following snippet of code:

{noformat}  
public static OntModel createModel(final String ontologyUri) {
final OntModel model = 
ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM);
model.read(ontologyUri);
return model;
}
{noformat}

I'm basically creating an OntModel and then pulling the OntClass and 
OntProperty fields out of the model for creating some Models.

  was:
I'm trying to create a simple interface/impl that will generate Prov-O RDF and 
place it on a JMS queue.  This object will live in an OSGi environment and be 
injected into various operating services working in a workflow.  I call the 
following piece of code:

public static OntModel createModel(final String ontologyUri) {
final OntModel model = 
ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM);
model.read(ontologyUri);
return model;
}

with the ontologyUri="http://www.w3.org/ns/prov-o;;  but when it gets to the 
ModelFactory.createOntologyModel(...) it chokes with the following stack trace. 
 
java.lang.IncompatibleClassChangeError: Class 
org.apache.jena.rdfxml.xmlinput.impl.RDFXMLParser$SAXParserWithEncodingCheck 
does not implement the requested interface org.xml.sax.XMLReader
at org.apache.jena.rdfxml.xmlinput.SAX2RDF.installHandlers(SAX2RDF.java:171)
at 
org.apache.jena.rdfxml.xmlinput.impl.RDFXMLParser.(RDFXMLParser.java:63)
at 
org.apache.jena.rdfxml.xmlinput.impl.RDFXMLParser.create(RDFXMLParser.java:127)
at org.apache.jena.rdfxml.xmlinput.JenaReader.(JenaReader.java:69)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
Method)[:1.8.0_11]
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)[:1.8.0_11]
at 

[jira] [Created] (JENA-1288) Reduce dependency on the Xerces jar.

2017-02-09 Thread Andy Seaborne (JIRA)
Andy Seaborne created JENA-1288:
---

 Summary: Reduce dependency on the Xerces jar.
 Key: JENA-1288
 URL: https://issues.apache.org/jira/browse/JENA-1288
 Project: Apache Jena
  Issue Type: Task
Affects Versions: Jena 3.2.0
Reporter: Andy Seaborne
Assignee: Andy Seaborne
Priority: Minor


There are facilities in the standard JDK that can be used instead of directly 
calling Xerces, specifically {{DatatypeConverter}}. With these changes, only 
one class relies on Xerces directly, {{XSDDatatype}}.

We have to be careful though - it is not perfect. I found that {{parseByte}} 
calls {{parseInt}} and casts the result to a java {{byte}} so it passes "300" 
and "3000" which are not valid byte lexical forms.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)