[jira] [Commented] (JENA-1463) RDF/XML parsing of file://hostname/ base URI miswrites URI

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1463:
---

This worked in 3.0.0, but is broken in all versions after.

> RDF/XML parsing of file://hostname/ base URI miswrites URI
> --
>
> Key: JENA-1463
> URL: https://issues.apache.org/jira/browse/JENA-1463
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, RDF/XML
>Affects Versions: Jena 3.0.1, Jena 3.1.0, Jena 3.1.1, Jena 3.2.0, Jena 
> 3.3.0, Jena 3.4.0, Jena 3.5.0, Jena 3.6.0
>Reporter: Stian Soiland-Reyes
>
> Similar to JENA-1462, but there seems to be special handling of file: URLs in 
> RDF/XML parsing, where parsing an RDF/XML file like:
> {code:xml}
>  xml:base="file://example.com/nested/"
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#";>
>   
> 
>   
> 
> {code}
> using 
> {code}
> RDFDataMgr.read(m, load("file-base.rdf"), Lang.RDFXML);
> {code}
> (Note, load() returns a InputStream, no explicit base)
> it comes out wrongly as:
> {code}
>  
> <http://www.w3.org/2000/01/rdf-schema#seeAlso>  .
> {code}
> Notice the hostname somehow became part of the path, now with a file:/// with 
> no hostname. 
> *Note: *https://tools.ietf.org/html/rfc8089#section-2 says that file URIs can 
> have a hostname, as well as the obvious hostname "localhost",  this is 
> typically used to address Windows shares no remote hosts.
> Equivalent in Turtle parses fine:
> {code}
> @base  .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>  rdfs:seeAlso  .
> {code}
> becomes:
> {code}
>  
> <http://www.w3.org/2000/01/rdf-schema#seeAlso>  .
> {code}
> Equivalent RDF/XML without xml:base and passing file://example.com/nested/ as 
> Base also fails: 
> {code:java}
> RDFDataMgr.read(m, load("rel.rdf"), "file://example.com/nested/", 
> Lang.RDFXML);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JENA-1462) RDF/XML parsing fails on newer/provisional/private URI schemes in base URI

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes updated JENA-1462:
--
Description: 
RIOT parsing RDF/XML with a base URI different from http/https/file, such as 
ssh://, fails.

See https://github.com/stain/jena-test-unregistered-iana for some tests I came 
up with.

Tests fail both for xml:base or if the base URI is provided to RDFDataMgr, but 
not if the URI is full inside the RDF/XML.


{code}
org.apache.jena.riot.RiotException: [line: 5, col: 40] {E214} Resolving against 
bad URI : 
at 
org.apache.jena.riot.TestParseURISchemeBases.sshBaseRDF(TestParseURISchemeBases.java:336)
{code}

This error message comes from ERR_RESOLVING_AGAINST_MALFORMED_BASE - for some 
reason the warning becomes an error as the IRI Factory used for creating the 
Base IRI within the RDF/XML parser is a bit too strict.

However I could not find anything in the specs:

* https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/
* https://www.w3.org/TR/2009/REC-xmlbase-20090128/
* https://www.ietf.org/rfc/rfc3986

that says "foreign" URI schemes should not be permitted. Anyway Jena's IANA 
list is probably out of date, as my tests shown.

This was initially detected in TAVERNA-1027 which tries to parse an RDF/XML 
with the [app:// URI scheme|https://www.w3.org/TR/app-uri/] , which is *not* 
registered with IANA https://www.iana.org/assignments/uri-schemes according to 
https://tools.ietf.org/html/bcp35

However, testing Jena with other permanent and provisional schemes from the 
registry, such as example://, ssh:// or a conformant private scheme with a 
domain-based name org.apache.jena.test:// also give the same error.  

IMHO they should all be understood in the same way as when parsing the Turtle 
examples, which don't fail.

I could trace this back to Jena 3.3.0, so I suspect this was introduced with 
JENA-1306. With versions before that all my tests *) work.

I'll raise a pull request with the junit tests, but have not been able to find 
a good way to fix it.

_*) There's a separate issue that hostnames in file://example.com/etc/passwd 
style URIs also seem to be misparsed in RDF/XML into 
file:///example.com/etc/passwd , reported separately as JENA-1463, that goes 
back till 3.0.1._

  was:
RIOT parsing RDF/XML with a base URI different from http/https/file, such as 
ssh://, fails.

See https://github.com/stain/jena-test-unregistered-iana for some tests I came 
up with.

Tests fail both for xml:base or if the base URI is provided to RDFDataMgr, but 
not if the URI is full inside the RDF/XML.


{code}
org.apache.jena.riot.RiotException: [line: 5, col: 40] {E214} Resolving against 
bad URI : 
at 
org.apache.jena.riot.TestParseURISchemeBases.sshBaseRDF(TestParseURISchemeBases.java:336)
{code}

This error message comes from ERR_RESOLVING_AGAINST_MALFORMED_BASE - for some 
reason the warning becomes an error as the IRI Factory used for creating the 
Base IRI within the RDF/XML parser is a bit too strict.

However I could not find anything in the specs:

* https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/
* https://www.w3.org/TR/2009/REC-xmlbase-20090128/
* https://www.ietf.org/rfc/rfc3986

that says "foreign" URI schemes should not be permitted. Anyway Jena's IANA 
list is probably out of date, as my tests shown.

This was initially detected in TAVERNA-1027 which tries to parse an RDF/XML 
with the [app:// URI scheme|https://www.w3.org/TR/app-uri/] , which is *not* 
registered with IANA https://www.iana.org/assignments/uri-schemes according to 
https://tools.ietf.org/html/bcp35

However, testing Jena with other permanent and provisional schemes from the 
registry, such as example://, ssh:// or a conformant private scheme with a 
domain-based name org.apache.jena.test:// also give the same error.  

IMHO they should all be understood in the same way as when parsing the Turtle 
examples, which don't fail.

I could trace this back to Jena 3.3.0, so I suspect this was introduced with 
JENA-1306. With versions before that all my tests *) work.

I'll raise a pull request with the junit tests, but have not been able to find 
a good way to fix it.

_*) There's a separate issue that hostnames in file://example.com/etc/passwd 
style URIs also seem to be misparsed in RDF/XML into 
file:///example.com/etc/passwd , which I'll report separately, that goes back 
till 3.0.1._


> RDF/XML parsing fails on newer/provisional/private URI schemes in base URI
> --
>
> Key: JENA-1462
> URL: https://issues.apache.org/jira/browse/JENA-1462
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, RDF/XML
>Affects Versions: Jena 3.3.0, Jena 3.4.0, Jena 3.5.0

[jira] [Created] (JENA-1463) RDF/XML parsing of file://hostname/ base URI miswrites URI

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created JENA-1463:
-

 Summary: RDF/XML parsing of file://hostname/ base URI miswrites URI
 Key: JENA-1463
 URL: https://issues.apache.org/jira/browse/JENA-1463
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ, RDF/XML
Affects Versions: Jena 3.6.0, Jena 3.5.0, Jena 3.4.0, Jena 3.3.0, Jena 
3.2.0, Jena 3.1.1, Jena 3.1.0, Jena 3.0.1
Reporter: Stian Soiland-Reyes


Similar to JENA-1462, but there seems to be special handling of file: URLs in 
RDF/XML parsing, where parsing an RDF/XML file like:

{code:xml}
http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#";>
  

  

{code}

using 

{code}
RDFDataMgr.read(m, load("file-base.rdf"), Lang.RDFXML);
{code}

(Note, load() returns a InputStream, no explicit base)

it comes out wrongly as:

{code}
 
<http://www.w3.org/2000/01/rdf-schema#seeAlso>  .
{code}

Notice the hostname somehow became part of the path, now with a file:/// with 
no hostname. 

*Note: *https://tools.ietf.org/html/rfc8089#section-2 says that file URIs can 
have a hostname, as well as the obvious hostname "localhost",  this is 
typically used to address Windows shares no remote hosts.

Equivalent in Turtle parses fine:

{code}
@base  .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

 rdfs:seeAlso  .
{code}

becomes:

{code}
 
<http://www.w3.org/2000/01/rdf-schema#seeAlso>  .
{code}

Equivalent RDF/XML without xml:base and passing file://example.com/nested/ as 
Base also fails: 

{code:java}
RDFDataMgr.read(m, load("rel.rdf"), "file://example.com/nested/", Lang.RDFXML);
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1462) RDF/XML parsing fails on newer/provisional/private URI schemes in base URI

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created JENA-1462:
-

 Summary: RDF/XML parsing fails on newer/provisional/private URI 
schemes in base URI
 Key: JENA-1462
 URL: https://issues.apache.org/jira/browse/JENA-1462
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ, RDF/XML
Affects Versions: Jena 3.6.0, Jena 3.5.0, Jena 3.4.0, Jena 3.3.0
 Environment: Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_151, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-42-generic", arch: "amd64", family: "unix"

Distributor ID: Ubuntu
Description:Ubuntu 16.04.3 LTS
Release:16.04
Codename:       xenial


    Reporter: Stian Soiland-Reyes


RIOT parsing RDF/XML with a base URI different from http/https/file, such as 
ssh://, fails.

See https://github.com/stain/jena-test-unregistered-iana for some tests I came 
up with.

Tests fail both for xml:base or if the base URI is provided to RDFDataMgr, but 
not if the URI is full inside the RDF/XML.


{code}
org.apache.jena.riot.RiotException: [line: 5, col: 40] {E214} Resolving against 
bad URI : 
at 
org.apache.jena.riot.TestParseURISchemeBases.sshBaseRDF(TestParseURISchemeBases.java:336)
{code}

This error message comes from ERR_RESOLVING_AGAINST_MALFORMED_BASE - for some 
reason the warning becomes an error as the IRI Factory used for creating the 
Base IRI within the RDF/XML parser is a bit too strict.

However I could not find anything in the specs:

* https://www.w3.org/TR/2014/REC-rdf-syntax-grammar-20140225/
* https://www.w3.org/TR/2009/REC-xmlbase-20090128/
* https://www.ietf.org/rfc/rfc3986

that says "foreign" URI schemes should not be permitted. Anyway Jena's IANA 
list is probably out of date, as my tests shown.

This was initially detected in TAVERNA-1027 which tries to parse an RDF/XML 
with the [app:// URI scheme|https://www.w3.org/TR/app-uri/] , which is *not* 
registered with IANA https://www.iana.org/assignments/uri-schemes according to 
https://tools.ietf.org/html/bcp35

However, testing Jena with other permanent and provisional schemes from the 
registry, such as example://, ssh:// or a conformant private scheme with a 
domain-based name org.apache.jena.test:// also give the same error.  

IMHO they should all be understood in the same way as when parsing the Turtle 
examples, which don't fail.

I could trace this back to Jena 3.3.0, so I suspect this was introduced with 
JENA-1306. With versions before that all my tests *) work.

I'll raise a pull request with the junit tests, but have not been able to find 
a good way to fix it.

_*) There's a separate issue that hostnames in file://example.com/etc/passwd 
style URIs also seem to be misparsed in RDF/XML into 
file:///example.com/etc/passwd , which I'll report separately, that goes back 
till 3.0.1._



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: eclipse and shaded guava?

[Stian Soiland-Reyes]

A workaround would be to only update the  version on
jena-shaded-guava when it needs to be changed, so the git SNAPSHOT master
could depend on the previous Jena-release of jena-guava from Maven Central.
One could then remove that module from the default profile and Eclipse &
friends would not see it's "source code". (It can be enabled in the release
profile which could also override dependency version to match)

(This kind of backwards dependency is generally discouraged, but needed as
there is just a single Jena git repository and corresponding releases)

Btw, you don't need the legacy mvn eclipse:eclipse as you are using the
recommended "Import existing Maven project" in Eclipse, which is happy
enough with the pom.xml files (except as we see for jena-shaded-guava)


On 11 Sep 2017 7:40 pm,  wrote:

This is a long-standing annoyance caused by our need to shade a modern
version of Guava into the code to avoid conflicting with the very old
version in Hadoop.

Do you have the jena0-shaded-guava project open in Eclipse? The problem
usually goes away if it is closed.


ajs6f
Chris Tomlinson wrote on 9/11/17 1:47 PM:

Hi,
>
> I’m having a bit of a hassle getting eclipse Mars 4.5.2 to hook up
> properly with imports like:
>
> import org.apache.jena.ext.com.google.common.cache.CacheBuilder ;
>> import org.apache.jena.ext.com.google.common.cache.CacheStats ;
>>
>
> I "git clone" jena and
>
> mvn clean install
> mvn eclipse:eclipse
>
> and then import the various submodules as existing maven projects into
> eclipse. Once the imports complete there are a few of the submodules with
> syntax errors in eclipse centered on the shaded guava. The projects with
> errors all have
>
> jena-shaded-guava
>
> as a project dependency in the .project and also a library reference to
> M2_REPO/com/google/guava/guava/21.0/guava-21.0.jar in the .classpath.
>
> The jena repo and submodules build and test fine from the command line.
>
> I’ve run maven update project on all of the jena projects and once the
> “update project” process completes the errors are cleared (a result of
> “clean projects” being checked) from all of the projects and then during
> the “building workspace” process the errors reappear one-by-one as the
> workspace is rebuilt.
>
> I appreciate any ideas about what I’m stumbling on.
>
> Thanks,
> Chris
>
>
>

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

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-909:
--

BTW, I have updated https://hub.docker.com/r/stain/jena/ and 
https://hub.docker.com/r/stain/jena-fuseki/ for the new Jena release.

I repeat that I think you should make a new jena-docker git repository and then 
register it directly at https://github.com/docker-library/official-images 
whenever there's a new Jena release.  The changes in this approach is fairly 
minimal, see 
https://github.com/stain/jena-docker/commit/20a01549fa4219a60327489c93dca301ee6ae148

Feel free to use my files from https://github.com/stain/jena-docker - I can 
contribute them again as a PR to that empty git repository if you so please 
(and remove any "stain" references :)

> 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)

Re: svn commit: r19560 - /release/jena/binaries/

[Stian Soiland-Reyes]

On Mon, 08 May 2017 13:15:34 -, aj...@apache.org wrote:
> Author: ajs6f
> Date: Mon May  8 13:15:33 2017
> New Revision: 19560
> 
> Log:
> Remove previous release
> 
> Removed:
> release/jena/binaries/
> 

Great work with the release!

For the future I would suggest not removing the old version from dist
(e.g. above the whole folder!) until the new one has propagated and the
download page is ready to be updated.



Otherwise for 24h+ there will be an impedence mismatch betweeen the
download pages and the various mirrors (as they catch up) as well as the
www.eu and www.us.apache.org mirrors (which update fastest).

You can check the mirror replication status on 
https://www.apache.org/mirrors/dist.html


For instance today right now, the md5 and PGP links from
http://jena.apache.org/download/index.cgi
are broken (404) as they point to for instance 
https://www.apache.org/dist/jena/binaries/apache-jena-3.2.0.tar.gz.md5
(which was deleted by the above commit)


Similarly the user might or might not (depending on their geo-IP) get
directed to a mirror where the 3.2.0 is no longer there -- 
for instance now 3.2.0 is missing from several of the suggested mirrors,
including:

http://www.mirrorservice.org/sites/ftp.apache.org/jena/binaries/
http://apache.mirrors.nublue.co.uk/jena/binaries/
http://mirror.catn.com/pub/apache/jena/binaries/


-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
http://orcid.org/-0001-9842-9718

Re: RDFConnection for Jena OSGi?

[Stian Soiland-Reyes]

Yeah, should be OK to add to the bundle - it will probably also work as is
outside configured manually, but better inside so it is in a single class
loader for the initialization step.

On 1 Mar 2017 9:06 pm, "Andy Seaborne"  wrote:

>
>
> On 01/03/17 16:39, A. Soroka wrote:
>
>> Our OSGi packaging currently does not include jena-rdfconnection.
>>
>> I don't think this is because anyone wanted to leave it out, this is
>> because doing my first release I dropped the ball here and forgot to add it.
>>
>> Any reason I should fix that now by adding jena-rdfconnection to the
>> modules that come with jena-osgi?
>>
>
> Good idea to include it.
>
> Andy
>
>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>>

Re: JPA contribution

[Stian Soiland-Reyes]

This is interesting! It seems to have a large overlap with the Juneau
project in the Incubator, which can map annotated beans from/to various
formats, including RDF with Jena.

http://juneau.incubator.apache.org/#about.html


Sesame in the olden days had something called Alibaba which was very
similar, but since abandoned, I think it also had such an EntityManager.

Would this module be particularly Jena-specific? I would think PA4RDF could
work well with Commons RDF and then be useful without having to pick an RDF
implementation.

(except I guess you use Jena for mapping to native types?).


On 21 Jan 2017 8:40 am, "Claude Warren"  wrote:

Greetings,

I have a project (PA4RDF) that provides persistence annotations that
read/write a Jena graph.

It basically turns any RDF subject into an object with the predicates
defining the properties of the object.

The current implementation can apply the annotations to interfaces,
abstract or concrete classes.  It has been used in several projects with
different corporate and government owners.

I would like to contribute the code and documentation to the Jena project
as an "extras" project.  Further information about the project and the code
can be found at https://github.com/Claudenw/PA4RDF.

Is there any objection to accepting this contribution?

Claude

--
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Jena now provides "Serializable" for Triple/Quad/Node?

[Stian Soiland-Reyes]

The serialization still use Thrift underneath - so if you are already
doing that I don't think you would gain much - perhaps save some code
and proxy objects?


See https://github.com/apache/jena/pull/191/files for the changes.

Basically there are wrapper objects SNode,STriple,SQuad which take
over the object stream and write the Thrift objects instead, and vice
versa on the way out.

Serializing a regular Node/Triple/Quad by default will delegate to
these - so it should be transparent to the code that is using them
directly as Serializable.

You can change the serialization globally by modifying
org.apache.jena.system.Serializer.setNodeSerializer and friends, see
SerializerRDF.

On 22 December 2016 at 12:43, Claude Warren  wrote:
> Greetings,
>
> Andy, in response to another topic, stated "Jena now provides
> "Serializable" for Triple/Quad/Node"
>
> As some of you know I am working on Jena on Cassandra (graph implementation
> complete) and want to know what the most efficient method of serializing
> nodes is.  I am using the Thrift library to convert to a RDF_TERM and
> serialzie that to a byte array.
>
> {code}
> private final TSerializer ser = new TSerializer();
>
> ...
>
> RDF_Term term = new RDF_Term(); ThriftConvert.toThrift(node, null, term,
> false); byte[] bary = ser.serialize(term);
>
> {code}
>
> What I require is that the node serialze into an array of bytes and be able
> to deserialize the same.
>
> Are the new serialization techniques for the Node faster than Thrift
> conversion?  Is there any special treatment required or is it just a case
> of ObjectOutputStream.write( node ) ?
>
> Where can I find more info/examples?
>
> Claude
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Re: Is there a singleton assembler pattern?

[Stian Soiland-Reyes]

Not sure what you mean by an assembler class.. I guess you mean
https://jena.apache.org/documentation/assembler/index.html
?


Best practice thread-safe singleton pattern in Java is:

public class Blah {
  /* Private constructor, use getInstance() */
  private Blah();

  private static class Singleton {
// will be late-bound by Singleton's class initializer
private final Blag INSTANCE = new Blah();
  }

  public static Blah getInstance() {
return Singleton.INSTANCE;
  }
}

Then of course any Assembler subclass can just use:

public class FooAssembler implements Assembler {
  private static Blah blah = Blah.getInstance();
}

which would then be bound at the first point of constructing
FooAssembler  or using FooAssembler static methods.


If it's more complicated (your singleton needs another singleton!) you
should rather extends Jena's initialization system so the order is
fixed.

https://jena.apache.org/documentation/notes/system-initialization.html


But to me both of these feel wrong as a Cassandra connection
presuambly is parameterized and could be multiple of - so a singleton
is not quite right.

On 5 December 2016 at 13:40, Claude Warren  wrote:
> I am looking for a way to create a single instance of an object across a
> number of assembler classes (Specifically a Cassandra connection), is there
> a standard singleton assembler pattern?  If so where can I find it?
>
> Claude
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Re: Eclipse and Shaded issues

[Stian Soiland-Reyes]

We can use the latest (e.g. previous) release of the jena-guava shading
instead of SNAPSHOT, it only needs to be put into SNAPSHOT if master
upgrades Guava. (Even then it could be a time stamped SNAPSHOT, which the
release plugin would query to fixate at release time)



On 2 Dec 2016 1:48 pm, "Andy Seaborne"  wrote:

> No need to even build from the command line.
>
> Just don't import the shaded module in Eclipse.  Or for that matter, any
> of the non-java modules like parent, top or top of JDBC etc.
>
> For any dependency that is not a project in Eclipse, Eclipse will do the
> maven thing and download the jars from the snapshot repo (which should be
> setup in your global maven settings).
>
> It is only at the point the RM bumps the version number does this need
> something slightly different - it's nice if the RM kicks off a rebuild on
> the central jenkins server rather than wiat for the overnight dev build.
>
> Or you can "mvn install" like Adam says as well.  "mvn -Pbootstrap" to do
> it the fast way - it does the parent and shaded guava.  Then the fast local
> build of the core modules "mvn "-Pdev" works.
>
> Andy
>
> On 02/12/16 12:31, A. Soroka wrote:
>
>> This is not a solution, it is a workaround, but I do a full build (at the
>> CLI) before importing. Then I just leave the Jena module project closed in
>> Eclipse. Then Eclipse tries to resolve it for the other projects like any
>> other Maven dependency, which works because I already built it and it is
>> available from my local repo.
>>
>> I agree that the whole thing is a bit odd, at best. At some point Rob had
>> a similar problem and I asked on-list why we shade Guava and it was
>> explained:
>>
>> https://lists.apache.org/thread.html/8fb52fc8f9d4cbdaa17853a
>> 07f8fcc16fcaaf7ef5d5cee07e38b6556@1433424160@%3Cdev.jena.apache.org%3E
>>
>> It is to avoid conflict with a transitive dependency on earlier versions
>> of Guava from Hadoop.
>>
>> https://issues.apache.org/jira/browse/HADOOP-10101
>>
>> looks like it last got a comment in October, when someone suggested that
>> Hadoop start shading _its_ archaic Guava, which (I think) would be both
>> polite and useful. There doesn't seem to be any action on that front, but I
>> am not at all involved with Hadoop.
>>
>> Another alternative was discussed in our thread above: managing and
>> releasing our shaded Guava independently of the main release. I think that
>> as long as we have to deal with the transitive issue, that is still a good
>> idea. But as Andy points out in that thread, it would create more work for
>> a release manager. I'm now a committer (which I was not then) so I can and
>> do heartily volunteer for that work for a shaded Guava subproject!
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>> On Dec 2, 2016, at 6:15 AM, Claude Warren  wrote:
>>>
>>> I know that Rob commented on something similar about a year ago but I am
>>> wondering if there is a common solution to the following problem:
>>>
>>> I do a gig clone of the Jean repository.
>>> I do an eclipse import existing maven from the root Jena directory.
>>>
>>> Eclipse gets stuck in a null pointer loop during the build. (Maven builds
>>> fine).
>>> jena-arq fails to build and continiously loops.
>>> If I build the shaded guava first and force the eclipse build to point to
>>> the jar it seems to solve the problem.
>>>
>>> Other packages will not compile because they have references to the
>>> shaded
>>> package names but the shaded jar is not on the classpath.
>>>
>>> Seems to me we need a way to make sure the shaded jar appears in the
>>> maven
>>> dependencies so that it will be included in the pom.  However, I think
>>> that
>>> since the shaded guava does not have any source eclipse does not run it
>>> and
>>> so does not build the jar that is needed by the other projects.  I am not
>>> certian this is the case.
>>>
>>> Anybody have a solution to making Jena compile in Eclipse directly after
>>> doing a git clone?
>>>
>>> Thx,
>>> Claude
>>>
>>> --
>>> I like: Like Like - The likeliest place on the web
>>> 
>>> LinkedIn: http://www.linkedin.com/in/claudewarren
>>>
>>
>>

Re: svn commit: r1768736 - in /jena/site/trunk/content/documentation/query: http-auth.mdtext service.mdtext

[Stian Soiland-Reyes]

No, I've only used the default caching mechanism, (as I wrote it ;-) - I
guess to do it properly we would then need to pass this through options or
the Documents loader to use.. :-/

On 9 Nov 2016 5:39 pm, "A. Soroka"  wrote:

> Hm, now I'm not sure whether I can give a good example of managing the
> JSON-LD HTTP client within Jena. oaj.riot.lang.JsonLDReader doesn't seem to
> allow users to get at the DocumentLoader instance in use, and that's where
> the JSON-LD docs show an override to use a specific client. I don't see any
> static state of the kind you describe in JSON-LD, Stian-- can you give me a
> pointer?
>
> ---
> A. Soroka
> The University of Virginia Library
>
> > On Nov 9, 2016, at 11:46 AM, Stian Soiland-Reyes 
> wrote:
> >
> > Yeah, as the client is set static inside JSON-LD Java it might not
> > good for be Jena  HttpOps to be "helpful" and propagate its client -
> > at least not without a flag.  But we can link to it from our
> > documentation.
> >
> > On 9 November 2016 at 16:39, A. Soroka  wrote:
> >> Hm, that's a really good point. I don't understand what's happening in
> JSON-LD very well, but I think you must be correct to say that it wouldn't
> take up a supplied client, because it wouldn't be using state from Jena.
> I'll check this a bit in the code and add a note as you suggest.
> >>
> >> ---
> >> A. Soroka
> >> The University of Virginia Library
> >>
> >>> On Nov 9, 2016, at 11:37 AM, Stian Soiland-Reyes 
> wrote:
> >>>
> >>> I think the new text looks good, quite easy to understand.
> >>>
> >>> Could you add a paragraph about when the configured client would be
> >>> used?   It might not be clear when this HttpClient would be accessed
> >>> or not.  For instance I assume it would be used for remote SPARQL
> >>> queries or loading of HTTP URLs from RDFDataMgr -- but may not be
> >>> propagated through to JSON-LD Java's @context loading - which has a
> >>> similar httpclient setting and documentation on how to configure
> >>> caching [1]
> >>>
> >>> [1] https://github.com/jsonld-java/jsonld-java#controlling-
> network-traffic
> >>>
> >>>
> >>>
> >>>
> >>> On 9 November 2016 at 15:42, A. Soroka  wrote:
> >>>> Done. I'll wait to hear from other folks before pulling a trigger on
> (re)publishing the site.
> >>>>
> >>>> ---
> >>>> A. Soroka
> >>>> The University of Virginia Library
> >>>>
> >>>>> On Nov 9, 2016, at 6:30 AM, Andy Seaborne  wrote:
> >>>>>
> >>>>> Great -
> >>>>>
> >>>>> One (!) other thing:
> >>>>>
> >>>>> A section specifically calling out migrating SPARQL remote calls:
> QueryExecutionFactory.sparqlService and QueryEngineHTTP.
> >>>>>
> >>>>> On the latter, older code may still be directly using
> QueryEngineHTTP.setBasicAuthentication
> >>>>>
> >>>>> Andy
> >>>>>
> >>>>> On 08/11/16 17:58, A. Soroka wrote:
> >>>>>> I've made those changes-- should be restaging now.
> >>>>>>
> >>>>>> ---
> >>>>>> A. Soroka
> >>>>>> The University of Virginia Library
> >>>>>>
> >>>>>>> On Nov 8, 2016, at 12:40 PM, Andy Seaborne 
> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 08/11/16 16:59, A. Soroka wrote:
> >>>>>>>> This commit includes the new docs for HTTP behavior in Jena
> 3.1.1. I can't find any way to see a view of this on the staging site--
> https://jena.staging.apache.org/ just seems to proxy
> https://cms.apache.org/, for some reason?
> >>>>>>>>
> >>>>>>>
> >>>>>>> It does not for me.
> >>>>>>>
> >>>>>>> Try http://jena.staging.apache.org/  (not https)
> >>>>>>>
> >>>>>>> PDF attached, cc'ed to you in the hope it get through.
> >>>>>>>
> >>>>>>> Comments:
> >>>>>>>
> >>>>>>> 1/ I'd put the current (3.1.1) text first and the previo

Re: svn commit: r1768736 - in /jena/site/trunk/content/documentation/query: http-auth.mdtext service.mdtext

[Stian Soiland-Reyes]

Yeah, as the client is set static inside JSON-LD Java it might not
good for be Jena  HttpOps to be "helpful" and propagate its client -
at least not without a flag.  But we can link to it from our
documentation.

On 9 November 2016 at 16:39, A. Soroka  wrote:
> Hm, that's a really good point. I don't understand what's happening in 
> JSON-LD very well, but I think you must be correct to say that it wouldn't 
> take up a supplied client, because it wouldn't be using state from Jena. I'll 
> check this a bit in the code and add a note as you suggest.
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Nov 9, 2016, at 11:37 AM, Stian Soiland-Reyes  wrote:
>>
>> I think the new text looks good, quite easy to understand.
>>
>> Could you add a paragraph about when the configured client would be
>> used?   It might not be clear when this HttpClient would be accessed
>> or not.  For instance I assume it would be used for remote SPARQL
>> queries or loading of HTTP URLs from RDFDataMgr -- but may not be
>> propagated through to JSON-LD Java's @context loading - which has a
>> similar httpclient setting and documentation on how to configure
>> caching [1]
>>
>> [1] https://github.com/jsonld-java/jsonld-java#controlling-network-traffic
>>
>>
>>
>>
>> On 9 November 2016 at 15:42, A. Soroka  wrote:
>>> Done. I'll wait to hear from other folks before pulling a trigger on 
>>> (re)publishing the site.
>>>
>>> ---
>>> A. Soroka
>>> The University of Virginia Library
>>>
>>>> On Nov 9, 2016, at 6:30 AM, Andy Seaborne  wrote:
>>>>
>>>> Great -
>>>>
>>>> One (!) other thing:
>>>>
>>>> A section specifically calling out migrating SPARQL remote calls: 
>>>> QueryExecutionFactory.sparqlService and QueryEngineHTTP.
>>>>
>>>> On the latter, older code may still be directly using 
>>>> QueryEngineHTTP.setBasicAuthentication
>>>>
>>>>  Andy
>>>>
>>>> On 08/11/16 17:58, A. Soroka wrote:
>>>>> I've made those changes-- should be restaging now.
>>>>>
>>>>> ---
>>>>> A. Soroka
>>>>> The University of Virginia Library
>>>>>
>>>>>> On Nov 8, 2016, at 12:40 PM, Andy Seaborne  wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/11/16 16:59, A. Soroka wrote:
>>>>>>> This commit includes the new docs for HTTP behavior in Jena 3.1.1. I 
>>>>>>> can't find any way to see a view of this on the staging site-- 
>>>>>>> https://jena.staging.apache.org/ just seems to proxy 
>>>>>>> https://cms.apache.org/, for some reason?
>>>>>>>
>>>>>>
>>>>>> It does not for me.
>>>>>>
>>>>>> Try http://jena.staging.apache.org/  (not https)
>>>>>>
>>>>>> PDF attached, cc'ed to you in the hope it get through.
>>>>>>
>>>>>> Comments:
>>>>>>
>>>>>> 1/ I'd put the current (3.1.1) text first and the previous second so the 
>>>>>> current is more visible.
>>>>>>
>>>>>> Links at the end of the intro to "current" and "previous", or in the 
>>>>>> intro as this difference is mentioned.
>>>>>>
>>>>>> 2/ Title tweaking:
>>>>>>
>>>>>> "HTTP Authentication after Jena 3.1.0" ->
>>>>>> "HTTP Authentication from Jena 3.1.1"
>>>>>>
>>>>>> "HTTP Authentication before Jena 3.1.0" =>
>>>>>> "HTTP Authentication from Jena 3.0.0 to 3.1.0"
>>>>>>
>>>>>> (so the range includes 3.1.0 !)
>>>>>>
>>>>>> Mentioning Jena 2.x is not necessary IMO - the additional detail adds 
>>>>>> confusion for current users and 3.x upgrading users (the majority).
>>>>>>
>>>>>> 3/
>>>>>> "Simple authentication using username and password"
>>>>>>
>>>>>> "Authenticating via a form"
>>>>>>
>>>>>> The  don't show up as different on teh screen for me so maybe bump 
>>>>>>  &qu

Re: svn commit: r1768736 - in /jena/site/trunk/content/documentation/query: http-auth.mdtext service.mdtext

[Stian Soiland-Reyes]

+
>>>>>> +## Other concerns
>>>>>> +
>>>>>> +### Debugging Authentication
>>>>>> +
>>>>>> +ARQ uses [Apache Http Client][14] for all its HTTP operations and this 
>>>>>> provides detailed logging information that can be used for debugging.  To
>>>>>> +see this information you need to configure your logging framework to 
>>>>>> set the `org.apache.http` package to either `DEBUG` or `TRACE` level.
>>>>>> +
>>>>>> +The `DEBUG` level will give you general diagnostic information about 
>>>>>> requests and responses while the `TRACE` level will give you detailed
>>>>>> +HTTP traces i.e. allow you to see the exact HTTP requests and responses 
>>>>>> which can be extremely useful for debugging authentication problems.
>>>>>> +
>>>>>> +### Authenticating to a SPARQL federated service
>>>>>> +
>>>>>> +ARQ allows the user to configure HTTP behavior to use on a 
>>>>>> per-`SERVICE` basis, including authentication behavior such as is 
>>>>>> described above. This works via the ARQ context. See [Basic Federated 
>>>>>> Query][5] for more information on configuring this functionality.
>>>>>> +
>>>>>> [1]: 
>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/atlas/web/auth/HttpAuthenticator.html
>>>>>> [2]: 
>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/atlas/web/auth/SimpleAuthenticator.html
>>>>>> [3]: 
>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/atlas/web/auth/ScopedAuthenticator.html
>>>>>> @@ -161,4 +231,7 @@ Note that the default authenticator may
>>>>>> [11]: 
>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/web/DatasetGraphAccessorHTTP.html
>>>>>> [12]: 
>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/atlas/web/auth/DelegatingAuthenticator.html
>>>>>> [13]: 
>>>>>> http://jena.apache.org/documentation/javadoc/arq/org/apache/jena/riot/web/HttpOp.html
>>>>>> -  [14]: http://hc.apache.org
>>>>>> \ No newline at end of file
>>>>>> +  [14]: http://hc.apache.org
>>>>>> +  [15]: 
>>>>>> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/HttpClient.html
>>>>>> +  [16]: https://hc.apache.org/httpcomponents-client-ga/examples.html
>>>>>> +  [17]: 
>>>>>> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/protocol/HttpClientContext.html
>>>>>> \ No newline at end of file
>>>>>>
>>>>>> Modified: jena/site/trunk/content/documentation/query/service.mdtext
>>>>>> URL: 
>>>>>> http://svn.apache.org/viewvc/jena/site/trunk/content/documentation/query/service.mdtext?rev=1768736&r1=1768735&r2=1768736&view=diff
>>>>>> ==
>>>>>> --- jena/site/trunk/content/documentation/query/service.mdtext (original)
>>>>>> +++ jena/site/trunk/content/documentation/query/service.mdtext Tue Nov  
>>>>>> 8 16:53:48 2016
>>>>>> @@ -48,19 +48,18 @@ distributed query evaluation. The algebr
>>>>>> without regard to how selective the pattern is. So the order of the
>>>>>> query will affect the speed of execution. Because it involves HTTP
>>>>>> operations, asking the query in the right order matters a lot.
>>>>>> -Don't ask for the whole of a bookstore just to find book whose
>>>>>> +Don't ask for the whole of a bookstore just to find a book whose
>>>>>> title comes from a local RDF file - ask the bookshop a query with
>>>>>> the title already bound from earlier in the query.
>>>>>>
>>>>>> ## Controlling `SERVICE` requests.
>>>>>>
>>>>>> -The `SERVICE` operation in a SPARQL query may be configured via the 
>>>>>> Context.
>>>>>> -The values for configuration can be set in the global context (accessed 
>>>>>> via
>>>>>> +The `SERVICE` operation in a SPARQL query may be configured via the 
>>>>>> Context. The values for configuration can be set in the global context 
>>>>>> (accessed via
>>>>>> `ARQ.getContext()`) or in the per-query execution context.
>>>>>>
>>>>>> The prefix  `srv:` is the IRI `<http://jena.hpl.hp.com/Service#>`.
>>>>>>
>>>>>> -### Summary
>>>>>> +### Configuration for ARQ through version 3.1.0
>>>>>>
>>>>>> Symbol | Usage
>>>>>> -- | -
>>>>>> @@ -71,7 +70,7 @@ Symbol | Usage
>>>>>> `srv:queryAuthPwd` |  Basic authentication
>>>>>> `srv:queryContext` | Per-endpoint configuration
>>>>>>
>>>>>> -### `srv:queryTimeout`
>>>>>> + `srv:queryTimeout`
>>>>>>
>>>>>> Set the connect and read timeouts for the query.
>>>>>>
>>>>>> @@ -86,21 +85,21 @@ read timout = 0
>>>>>>
>>>>>> Values of 0 indicate no timeout and service operation will wait until 
>>>>>> the remote server responds.
>>>>>>
>>>>>> -### `srv:queryGzip`
>>>>>> + `srv:queryGzip`
>>>>>>
>>>>>> Sets the allow Gzip flag.
>>>>>>
>>>>>> Boolean: True indicates that gzip compressed data is acceptable.
>>>>>> false
>>>>>>
>>>>>> -### `srv:queryDeflate`
>>>>>> + `srv:queryDeflate`
>>>>>>
>>>>>> Sets the allow Deflate flag.
>>>>>>
>>>>>> Boolean: True indicates that deflate compression is acceptable
>>>>>> False
>>>>>>
>>>>>> -### `srv:queryAuthUser`
>>>>>> + `srv:queryAuthUser`
>>>>>>
>>>>>> Sets the user id for basic auth.
>>>>>>
>>>>>> @@ -108,7 +107,7 @@ String: The user id to log in with
>>>>>>
>>>>>> If null or null length no user id is sent.
>>>>>>
>>>>>> -### `srv:queryAuthPwd`
>>>>>> + `srv:queryAuthPwd`
>>>>>>
>>>>>> Sets the password for basic auth.
>>>>>>
>>>>>> @@ -116,13 +115,43 @@ String: The password to log in with.
>>>>>>
>>>>>> If null or null length no password is sent.
>>>>>>
>>>>>> -### srv:serviceContext
>>>>>> + `srv:serviceContext`
>>>>>> Provides a mechanism to override system context settings on a per URI 
>>>>>> basis.
>>>>>>
>>>>>> The value is a `Map` where the map key is the URI of the 
>>>>>> service endpoint, and the `Context` is a set of values to override the 
>>>>>> default values.
>>>>>>
>>>>>> If a context is provided for the URI the system context is copied and 
>>>>>> the URI specific values are then copied in.  This ensures that any URI 
>>>>>> specific settings will be used.
>>>>>>
>>>>>> +### Configuration for ARQ after version 3.1.0
>>>>>>
>>>>>> +Symbol | Usage | Default
>>>>>> +-- | - | ---
>>>>>> +`srv:queryTimeout` | Set timeouts | none
>>>>>> +`srv:queryCompression` | Enable use of deflation and GZip | true
>>>>>> +`srv:queryClient` | Enable use of a specific client | none
>>>>>> +`srv:queryContext` | Per-endpoint configuration | none
>>>>>> +
>>>>>> + `srv:queryTimeout`
>>>>>> +
>>>>>> +As documented above.
>>>>>> +
>>>>>> +
>>>>>> + `srv:queryCompression`
>>>>>> +
>>>>>> +Sets the flag for use of deflation and GZip.
>>>>>> +
>>>>>> +Boolean: True indicates that gzip compressed data is acceptable.
>>>>>> +
>>>>>> + `srv:queryClient`
>>>>>> +
>>>>>> +Enable use of a specific client
>>>>>> +
>>>>>> +Provides a slot for a specific [HttpClient][1] for use with a specific 
>>>>>> `SERVICE`
>>>>>> +
>>>>>> + `srv:serviceContext`
>>>>>> +
>>>>>> +As documented above.
>>>>>>
>>>>>> [ARQ documentation index](index.html)
>>>>>> +
>>>>>> +[1]: 
>>>>>> https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/HttpClient.html
>>>>>>
>>>>>>
>>>>>
>>>
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Re: [jira] [Commented] (JENA-1233) Make RDF primitives Serializable

[Stian Soiland-Reyes]

Wonder what a bit of winter air does.. I checked deeper - I think the
code should be safe.

The new Jena code doesn't make it's own ObjectInputStream and as your
wrapper classes basically hijack the java.io.ObjectOutputStream and
java.io.ObjectInputStream (given to Thrift as pure
Input/OutputStream), then .readObject() won't be called there at all.

As well you have added the guard exception throws by Node/Triple/Quads
n readObject / writeObject()  if a serializer has not been set, so
they should also be safe.

I've suggested to add "transient" to the wrapped Quad/Triple/Node
fields of the S* classes to clarify for future developers that they
are not actually serialized in the ObjectOutputStream, but I don't
think it is needed for security reasons.

${insertImNotASecurityDisclaimerHere}

On 9 November 2016 at 14:49, Stian Soiland-Reyes  wrote:
> Just raising it as something to check.. I don't think your code looks
> particularly vulnerable, as the main job is done by Thrift.
>
>
> About "final" - good practice is to use 'final' unless a class is
> meant to be extended. As the S classes are just serialisation capsules
> I think this would be the case here:
>
> http://www.yegor256.com/2014/11/20/seven-virtues-of-good-object.html#7-his-class-is-either-final-or-abstract
>
> (Warning: quite opinionated author :)
>
>
> There's been quite a few CVEs raised because of unchecked
> Serialization usage in Java within libraries - where unknowing API
> users (who for some reason decide to do untrusted Java deserialization
> of their own code) get an additional drive-by serialization attack
> vector open via their dependencies.
>
> Here are some guidance:
>
>   http://www.oracle.com/technetwork/java/seccodeguide-139067.html#8
>   https://christian-schneider.net/JavaDeserializationSecurityFAQ.html#main
>
>
> I liked these slides, by Christian Schneider who helped me fix
> CVE-2016-2510 in Beanshell:
>
> http://www.slideshare.net/cschneider4711/owasp-benelux-day-2016-serial-killer-silently-pwning-your-java-endpoints
>
>
> I'm afraid I don't understand Java serialization enough to look
> further into this further without a fair amount of effort.
>
> On 9 November 2016 at 09:39, Andy Seaborne  wrote:
>> On 08/11/16 16:58, Stian Soiland-Reyes wrote:
>>>
>>> Looks like an OK solutions. Could the S classes be made "final"..?
>>>
>>> There are some security concerns with readObject() that can expose remote
>>> code execution, by for instance building a sorted collection with
>>> comparable objects, where one of those objects allow custom comparison
>>> code
>>> (e.g. a groovy script)
>>
>>
>> Indeed there can be but I don't understand what you claiming in this
>> message.  It is all too vague and hints of "maybe".
>>
>> Are you claiming there is a security issue? Something specific to this code?
>> or Java serializable in general? or whenever data is being read in?
>>
>> As S* are injectable, I don't see that final makes a difference one way of
>> the other.  I can add it - does no harm - but it does not relate to the
>> serialiablity of Node because S* are not mandated and enforced.
>>
>> Note that the serialization object and the UID comes from the injected code
>> and not from class Node/Triple/Quad.  And it's written into publicly access
>> source code.
>>
>> SNode, STriple, SQuad are not composite Serialiable nor collections. They do
>> not pull in any other Serializable.
>>
>> STriple, SQuad do not use SNode.
>>
>> SNode does not use any other serializable.  It directly encoding it's own
>> format into the stream.  This is intentional to avoid recursively invoking
>> Serializable
>>
>> Andy
>>
>>
>>> https://www.owasp.org/index.php/Deserialization_of_untrusted_data
>>>
>>> The problem is that it is possible to deserialize anything on the class
>>> path, not just the type you cast to in the end. If an evil object stream
>>> contains such collections then the damage might have already been done.
>>>
>>> And this could happen when an application is deserializing non-Jena
>>> objects
>>> but have Jena on the class path.
>>>
>>> It would be good checking if any other measures are needed. E.g. is it
>>> possible to do similar nasty things in the thrift stream (beyond just
>>> having massively large strings)? I would think not, but worth double
>>> checking.
>>>
>>> On 6 Nov 2016 8:17 pm, "Andy Seaborne (JIRA)&q

Re: [jira] [Commented] (JENA-1233) Make RDF primitives Serializable

[Stian Soiland-Reyes]

Just raising it as something to check.. I don't think your code looks
particularly vulnerable, as the main job is done by Thrift.


About "final" - good practice is to use 'final' unless a class is
meant to be extended. As the S classes are just serialisation capsules
I think this would be the case here:

http://www.yegor256.com/2014/11/20/seven-virtues-of-good-object.html#7-his-class-is-either-final-or-abstract

(Warning: quite opinionated author :)


There's been quite a few CVEs raised because of unchecked
Serialization usage in Java within libraries - where unknowing API
users (who for some reason decide to do untrusted Java deserialization
of their own code) get an additional drive-by serialization attack
vector open via their dependencies.

Here are some guidance:

  http://www.oracle.com/technetwork/java/seccodeguide-139067.html#8
  https://christian-schneider.net/JavaDeserializationSecurityFAQ.html#main


I liked these slides, by Christian Schneider who helped me fix
CVE-2016-2510 in Beanshell:

http://www.slideshare.net/cschneider4711/owasp-benelux-day-2016-serial-killer-silently-pwning-your-java-endpoints


I'm afraid I don't understand Java serialization enough to look
further into this further without a fair amount of effort.

On 9 November 2016 at 09:39, Andy Seaborne  wrote:
> On 08/11/16 16:58, Stian Soiland-Reyes wrote:
>>
>> Looks like an OK solutions. Could the S classes be made "final"..?
>>
>> There are some security concerns with readObject() that can expose remote
>> code execution, by for instance building a sorted collection with
>> comparable objects, where one of those objects allow custom comparison
>> code
>> (e.g. a groovy script)
>
>
> Indeed there can be but I don't understand what you claiming in this
> message.  It is all too vague and hints of "maybe".
>
> Are you claiming there is a security issue? Something specific to this code?
> or Java serializable in general? or whenever data is being read in?
>
> As S* are injectable, I don't see that final makes a difference one way of
> the other.  I can add it - does no harm - but it does not relate to the
> serialiablity of Node because S* are not mandated and enforced.
>
> Note that the serialization object and the UID comes from the injected code
> and not from class Node/Triple/Quad.  And it's written into publicly access
> source code.
>
> SNode, STriple, SQuad are not composite Serialiable nor collections. They do
> not pull in any other Serializable.
>
> STriple, SQuad do not use SNode.
>
> SNode does not use any other serializable.  It directly encoding it's own
> format into the stream.  This is intentional to avoid recursively invoking
> Serializable
>
> Andy
>
>
>> https://www.owasp.org/index.php/Deserialization_of_untrusted_data
>>
>> The problem is that it is possible to deserialize anything on the class
>> path, not just the type you cast to in the end. If an evil object stream
>> contains such collections then the damage might have already been done.
>>
>> And this could happen when an application is deserializing non-Jena
>> objects
>> but have Jena on the class path.
>>
>> It would be good checking if any other measures are needed. E.g. is it
>> possible to do similar nasty things in the thrift stream (beyond just
>> having massively large strings)? I would think not, but worth double
>> checking.
>>
>> On 6 Nov 2016 8:17 pm, "Andy Seaborne (JIRA)"  wrote:
>>
>>>
>>> [ https://issues.apache.org/jira/browse/JENA-1233?page=
>>> com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>> tabpanel&focusedCommentId=15642341#comment-15642341 ]
>>>
>>> Andy Seaborne commented on JENA-1233:
>>> -
>>>
>>> A plan:
>>>
>>> Java serialization has a mechanism to allow an object to be serialized by
>>> another object. This plan uses that to put the serialization code into
>>> ARQ.
>>>
>>> https://docs.oracle.com/javase/8/docs/platform/
>>> serialization/spec/serialTOC.html
>>>
>>> We need to decouple {{Node}} and {{Triple}} serialization otherwise we
>>> limit the possible serialization implementation to what is available to
>>> jena-core.
>>>
>>> In order to make {{Node}} and {{Triple}} serializable, use
>>> {{writeReplace}} and {{readResolve}} to produce a serializable wrapper.
>>> These work by inserting a different object into the serialization stream.
>>> The {{SNode}}/{{STriple}}/{{SQuad}} in the explicit wrapper.
>&

Re: [jira] [Commented] (JENA-1233) Make RDF primitives Serializable

[Stian Soiland-Reyes]

Looks like an OK solutions. Could the S classes be made "final"..?

There are some security concerns with readObject() that can expose remote
code execution, by for instance building a sorted collection with
comparable objects, where one of those objects allow custom comparison code
(e.g. a groovy script)

https://www.owasp.org/index.php/Deserialization_of_untrusted_data

The problem is that it is possible to deserialize anything on the class
path, not just the type you cast to in the end. If an evil object stream
contains such collections then the damage might have already been done.

And this could happen when an application is deserializing non-Jena objects
but have Jena on the class path.

It would be good checking if any other measures are needed. E.g. is it
possible to do similar nasty things in the thrift stream (beyond just
having massively large strings)? I would think not, but worth double
checking.

On 6 Nov 2016 8:17 pm, "Andy Seaborne (JIRA)"  wrote:

>
> [ https://issues.apache.org/jira/browse/JENA-1233?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=15642341#comment-15642341 ]
>
> Andy Seaborne commented on JENA-1233:
> -
>
> A plan:
>
> Java serialization has a mechanism to allow an object to be serialized by
> another object. This plan uses that to put the serialization code into ARQ.
>
> https://docs.oracle.com/javase/8/docs/platform/
> serialization/spec/serialTOC.html
>
> We need to decouple {{Node}} and {{Triple}} serialization otherwise we
> limit the possible serialization implementation to what is available to
> jena-core.
>
> In order to make {{Node}} and {{Triple}} serializable, use
> {{writeReplace}} and {{readResolve}} to produce a serializable wrapper.
> These work by inserting a different object into the serialization stream.
> The {{SNode}}/{{STriple}}/{{SQuad}} in the explicit wrapper.
>
> {{Node}}/{{Triple}}/{{Quad}} have a function called in {{writeReplace}}
> injected so the serialization is not fixed.  The binary form using Thrift
> will be injected by ARQ when Jena initializes.
>
> Sketch (a better injection mechanism is needed to avoid cluttering the API
> of {{Node}}):
> {noformat}
> public abstract class Node implements Serializable {
> // Returned Object must provide "readResolve()" that returns a Node.
> public static Function replacement = null ;
> protected Object writeReplace() throws ObjectStreamException {
> return replacement.apply(this);
> }
> ...
> {noformat}
> NB No "serialVersionUID" here - it is given in the replacement Object so
> different serializations will not get mixed up.
>
> This means that jena-core, on its own without ARQ, does not support
> serialization of {{Node}} and {{Triple}}. As running jena-core without
> jena-arq is to be discouraged anyway, that is no bad thing. A string based
> form could be provided, but not supporting quad.
>
> Alt plan: have two injected functions for {{writeObject}} and
> {{readObject}}, then the serialVersionUID comes from {{Node}} and is the
> same for all implementations.
>
> I don't see sufficient advantage of this. It looks more like a "normal"
> implementation, rather than the {{writeReplace}}/{{readResolve}} dance,
> and does not create the short lived, intermediate object but with the
> impact of same serialVersionUID across implementations.
>
>
> > Make RDF primitives Serializable
> > 
> >
> > Key: JENA-1233
> > URL: https://issues.apache.org/jira/browse/JENA-1233
> > Project: Apache Jena
> >  Issue Type: Improvement
> >  Components: Elephas
> >Affects Versions: Jena 3.1.0
> >Reporter: Itsuki Toyota
> >
> > I always use Jena when I handle RDF data with Apache Spark.
> > However, when I want to store resulting RDD data (ex. RDD[Triple]) in
> binary format, I can't call RDD.saveAsObjectFile method.
> > It's because RDD.saveAsObjectFile requires java.io.Serializable
> interface.
> > See the following code.
> > https://github.com/apache/spark/blob/v1.6.0/core/src/
> main/scala/org/apache/spark/rdd/RDD.scala#L1469
> > https://github.com/apache/spark/blob/v1.6.0/core/src/
> main/scala/org/apache/spark/util/Utils.scala#L79-L86
> > You can see that
> > 1) RDD.saveAsObjectFile calls Util.serialize method
> > 2) Util.serialize method requires the RDD-wrapped object implementing
> java.io.Serializable interface. For example, if you want to save a
> RDD[Triple] object, Triple must implements java.io.Serializable.
> > So why not implement java.io.Serializable ?
> > I think it will improve the usability in Apache Spark.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Re: Next version?

[Stian Soiland-Reyes]

+1

On 8 Nov 2016 1:56 pm, "Andy Seaborne"  wrote:

> Well, 3.1.1 should have been 3.2.0 so lets pretend 3.1.1 is 3.2.0-beta.
> :-)  So if we have to get out a bug-fixing "3.1.2" or anything even quite
> soon, 3.2.0 is still a reasonable choice.
>
> It is much easier to set the version now. It sets into all sorts of places
> like written down in JIRA and email.
>
> Andy
>
> On 08/11/16 13:26, Claude Warren wrote:
>
>> Should we wait for the change that causes the version jump first.  I would
>> think that we would have 3.1.2-SNAPSHOT and then *if* JENA-1250 causes an
>> incompatible change jump the version to 3.2.0-SNAPSHOT
>>
>> But I can go either way
>>
>> +0
>>
>>
>> On Tue, Nov 8, 2016 at 11:37 AM, Osma Suominen > >
>> wrote:
>>
>> 08.11.2016, 12:33, Andy Seaborne wrote:
>>>
>>> Should the next version be 3.2.0?

 The Lucene file format may well change.

 If we want that, I'll go and update the POM versions.


>>> +1 for calling it 3.2.0.
>>>
>>> Yes, the Lucene upgrade (JENA-1250) will very likely go into the next
>>> release in some form and change the Lucene index on-disk format.
>>>
>>> -Osma
>>>
>>>
>>> --
>>> Osma Suominen
>>> D.Sc. (Tech), Information Systems Specialist
>>> National Library of Finland
>>> P.O. Box 26 (Kaikukatu 4)
>>> 00014 HELSINGIN YLIOPISTO
>>> Tel. +358 50 3199529
>>> osma.suomi...@helsinki.fi
>>> http://www.nationallibrary.fi
>>>
>>>
>>
>>
>>

Re: How to edit Documentation ?

[Stian Soiland-Reyes]

The CMS is very based on SVN, so you need to click the Update button for
the equivalent of "svn update" of your working directory. It might be you
have to climb one folder up within CMS before updating.

On 7 Nov 2016 9:25 pm, "Claude Warren"  wrote:

> I tried using a private browsing window in Firefox -- no change. :(
>
> On Mon, Nov 7, 2016 at 9:07 PM, A. Soroka  wrote:
>
> > You may be having the problems that I have repeatedly had with browser
> > caching. An alternative move is to check out the SVN of the site from
> >
> > https://svn.apache.org/repos/asf/jena/site/trunk
> >
> > and edit it directly. You won't get the preview without setting up your
> > own tooling, which is annoying.
> >
> > ---
> > A. Soroka
> > The University of Virginia Library
> >
> > > On Nov 7, 2016, at 4:05 PM, Claude Warren  wrote:
> > >
> > > I know I have asked this before and even gotten good answers, but I
> can't
> > > seem to find the old messages so 
> > >
> > > How do I get a copy of http://jena.apache.org/documentation/ that I
> can
> > > edit.
> > >
> > > The "improve this page" link does not seem to work for me.  I get very
> > old
> > > stuff.
> > >
> > > Claude
> > >
> > > --
> > > I like: Like Like - The likeliest place on the web
> > > 
> > > LinkedIn: http://www.linkedin.com/in/claudewarren
> >
> >
>
>
> --
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [] Release Apache jena 3.1.1 (2nd)

[Stian Soiland-Reyes]

My apologies for finding this so late. As you will know, Commons RDF
has just recently moved into preparing a release candidate that
includes Jena support, which I originally had prepared using Jena
3.1.0. As that RC was dropped for other reasons, I thought I could
have a go at using the next Jena 3.1.1 as dependency.

I don't have much time to try out Jena while it's under development,
as building Jena takes a very long time, also I didn't consider the
SNAPSHOTs earlier as we didn't require what was new.


BTW - I changed my vote to -0 as I don't think you need to block the
release for this, but wanted to report what I got.   As RM you can of
course take it or leave it :)

On 7 November 2016 at 13:56, Andy Seaborne  wrote:
>
> On 07/11/16 00:05, Stian Soiland-Reyes wrote:
>>
>> I'm afraid my vote is:
>>
>> -1 (non-binding)
>>
>> because of broken initializers and confusing LICENSE in source archive.
>
>
>
>> - repository JARs/POMs; broken initializers?
>
>
> IMO A single problem is not grounds for redoing a release.  Just look at
> JIRA.
>
> What is more, 3.1.1 has been signalled for over 2 months. If you could test
> against development snapshots much earlier in the cycle that would be
> helpful and then raise issues before the RM invests time in the release
> process.
>
>> Another thing, LICENSE file of jena-3.1.1-source-release.zip says
>>
>>
>>> The following files contain code contributed by Plugged In Software:
>>>
>>> src/main/java/org/apache/jena/rdf/arp/ExtendedHandler.java
>>> src/main/java/org/apache/jena/rdf/arp/impl/XMLHandler.java
>>> src/main/java/org/apache/jena/rdf/arp/ARP.java
>>
>>
>> but the correct file paths are presumably these under jena-core/ and
>> in different packages:
>>
>>
>> jena-core/src/main/java/org/apache/jena/rdfxml/xmlinput/ExtendedHandler.java
>>
>> jena-core/src/main/java/org/apache/jena/rdfxml/xmlinput/impl/XMLHandler.java
>> jena-core/src/main/java/org/apache/jena/rdfxml/xmlinput/ARP.java
>>
>> I wonder why these files have BOTH the Apache license and BSD
>> license..
>
>
> It is a combination of a contribution (BSD) and later work (AL).
>
> Back when it was contributed, licensing issues were not so clearly expressed
> (anywhere, not just Jena).
>
> We could not ask Plugged In Software for a Software Grant (the company did
> not exist).
>
>> Related in NOTICE:
>>
>>> Apache Jena
>>> Copyright 2011, 2012, 2013, 2014, 2015, 2016 The Apache Software
>>> Foundation
>
>
> That can be changed.
>
>>> ..
>>>   - Copyright 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
>>> Hewlett-Packard Development Company, LP
>
>
> Not ours to change.
>
>>
>>
>> I guess no need to list all the years, 2011-2016 and 2001-2009 would
>> suffice.
>
>
> There are, or at least were, differences of opinion in legal circles about
> that.
>
>> I would have called this version 3.2.0 instead - I remember several
>> times when a "patch" update of Jena has lots of big changes in other
>> code; I guess after 6 months of hard work we can't aim for patch
>> compatibility anymore so it's just fair to go for 3.2.0 even if
>> there's nothing new politically.
>
>
> See discussion about a 3 month release cycle.
>
> Andy



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Re: [VOTE] Release Apache jena 3.1.1 (2nd)

[Stian Soiland-Reyes]

Raised
https://issues.apache.org/jira/browse/JENA-1258

Proposed fix:
https://github.com/apache/jena/pull/189



On 7 November 2016 at 00:29, Stian Soiland-Reyes  wrote:
> I'll change my vote to a -0 as an ARQ.init(); is sufficient to fix it
> for me. Nevertheless, not the kind of bug I would expect from a patch
> update..
>
> On 7 November 2016 at 00:25, Stian Soiland-Reyes  wrote:
>> My problem seems to be with early access of NodeFactory and then
>> org.apache.jena.riot.out.NodeFmtLib, e.g.
>>
>> @Test
>> public void testName() throws Exception {
>> Node node = NodeFactory.createLiteral("Hello world", "en");
>> assertEquals("\"Hello world\"@en", NodeFmtLib.str(node));
>> }
>>
>> Fails with:
>>
>> java.lang.ExceptionInInitializerError
>> at org.apache.jena.riot.out.NodeFmtLib.(NodeFmtLib.java:55)
>> at org.apache.commons.rdf.jena.TestNodeStuff.testName(TestNodeStuff.java:15)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at 
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>> at 
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>> at 
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>> at 
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>> at 
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>> at 
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>> at 
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>> at 
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>> at 
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>> at 
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
>> at 
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>> at 
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
>> Caused by: org.apache.jena.sparql.ARQException: Context key is null
>> at org.apache.jena.sparql.util.Context._put(Context.java:102)
>> at org.apache.jena.sparql.util.Context.set(Context.java:94)
>> at 
>> org.apache.jena.sparql.function.FunctionRegistry.set(FunctionRegistry.java:74)
>> at 
>> org.apache.jena.sparql.function.FunctionRegistry.init(FunctionRegistry.java:48)
>> at org.apache.jena.query.ARQ.init(ARQ.java:592)
>> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
>> at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119)
>> at java.util.ArrayList.forEach(ArrayList.java:1249)
>> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194)
>> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171)
>> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117)
>> at org.apache.jena.sparql.ARQConstants.(ARQConstants.java:35)
>> ... 25 more
>>
>>
>>
>> On 7 November 2016 at 00:05, Stian Soiland-Reyes  wrote:
>>> Thanks for putting together a 3.1.1 RC!
>>>
>>>
>>> I'm afraid my vote is:
>>>
>>> -1 (non-binding)
>>>
>>> because of broken initializers and confusing LICENSE in source archive.
>>>
>>>
>>> Checked:
>>>
>>> + GPG signatures
>>> + source zip matches git commit; adds only (empty) DEPENDENCIES and
>>> dependency-reduced-pom.xml
>>> - Hashes - you didn't provide dist svn revision or its sha1 hashes,
>>> I'll assume rev 16841
>>> - repository JARs/POMs; broken initializers?
>>> - LICENSE;

[jira] [Commented] (JENA-1258) Context key is null (ARQConstants.registryFunctions) via NodeFmtLib

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1258:
---

Other code using {{ARQConstant}} without a {{static}} initialization look a bit 
more excotic, e.g. {{org.apache.jena.riot.system.RiotLib}}, 
{{org.apache.jena.sdb.engine.QueryEngineSDB}}, 
{{org.apache.jena.sparql.algebra.AlgebraQuad}}, 
{{org.apache.jena.sparql.core.Var}}

> Context key is null (ARQConstants.registryFunctions) via NodeFmtLib
> ---
>
> Key: JENA-1258
> URL: https://issues.apache.org/jira/browse/JENA-1258
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.1.1
>    Reporter: Stian Soiland-Reyes
>
> This small test, with no ARQ.init(), causes a problem in initializers:
> {code}
> @Test
> public void testName() throws Exception {
> Node node = NodeFactory.createLiteral("Hello world", "en");
> assertEquals("\"Hello world\"@en", NodeFmtLib.str(node));
> }
> {code}
> It fails with:
> {code}
> java.lang.ExceptionInInitializerError
> at org.apache.jena.riot.out.NodeFmtLib.(NodeFmtLib.java:55)
> at org.apache.commons.rdf.jena.TestNodeStuff.testName(TestNodeStuff.java:15)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.jena.sparql.ARQException: Context key is null
> at org.apache.jena.sparql.util.Context._put(Context.java:102)
> at org.apache.jena.sparql.util.Context.set(Context.java:94)
> at 
> org.apache.jena.sparql.function.FunctionRegistry.set(FunctionRegistry.java:74)
> at 
> org.apache.jena.sparql.function.FunctionRegistry.init(FunctionRegistry.java:48)
> at org.apache.jena.query.ARQ.init(ARQ.java:592)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117)
> at org.apache.jena.sparql.ARQConstants.(ARQConstants.java:35)
> ... 25 more
> {code}
> closer debugging reveals that it is trying to set a context with the static 
> {{ARQConstants.registryFunctions}} which is still null:
> {code}
> Thread [main] (Suspended (breakpoint at line 102 in Context)) 
>   owns: Object  (id=65)   
>   owns: Class (org.apache.jena.system.JenaSystem) (id=61)  
>   owns: Object  (id=66)   
>   Context._put(Symbol, Object) line: 102  
>   Context.set(Symbol, Object) li

[jira] [Commented] (JENA-1258) Context key is null (ARQConstants.registryFunctions) via NodeFmtLib

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1258:
---

Early access to {{NodeFmtLib}} is not needed to reproduce - the problem is 
ARQConstants:

{code}
RDFS.label.asNode().toString(ARQConstants.getGlobalPrefixMap());
{code}

In 3.1.0 this will print out {{rdfs:label}, while 3.1.1 RC1 fails with the 
"Contexts key is null" exception.  ARQConstants is however documented as 
"internal", but NodeFmtLib is exposed as "Presentation utilitiles for Nodes, 
Triples, Quads and more."

The quick fix is for {{NodeFmtLib}} to also do {{JenaSystem.init()}}.

The "real" problem I guess is way too many static fields, methods and 
initializers.. If ARQConstants is triggered first, it fails to finish 
initializing its fields.

We probably need Jena 4 to fix that, get rid of all static fields and methods 
for anything non-trivial.


> Context key is null (ARQConstants.registryFunctions) via NodeFmtLib
> ---
>
> Key: JENA-1258
> URL: https://issues.apache.org/jira/browse/JENA-1258
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.1.1
>Reporter: Stian Soiland-Reyes
>
> This small test, with no ARQ.init(), causes a problem in initializers:
> {code}
> @Test
> public void testName() throws Exception {
> Node node = NodeFactory.createLiteral("Hello world", "en");
> assertEquals("\"Hello world\"@en", NodeFmtLib.str(node));
> }
> {code}
> It fails with:
> {code}
> java.lang.ExceptionInInitializerError
> at org.apache.jena.riot.out.NodeFmtLib.(NodeFmtLib.java:55)
> at org.apache.commons.rdf.jena.TestNodeStuff.testName(TestNodeStuff.java:15)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.jena.sparql.ARQException: Context key is null
> at org.apache.jena.sparql.util.Context._put(Context.java:102)
> at org.apache.jena.sparql.util.Context.set(Context.java:94)
> at 
> org.apache.jena.sparql.function.FunctionRegistry.set(FunctionRegistry.java:74)
> at 
> org.apache.jena.sparql.function.FunctionRegistry.init(FunctionRegistry.java:48)
> at org.apache.jena.query.ARQ.init(ARQ.java:592)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117)
> at org.apach

[jira] [Commented] (JENA-1258) Context key is null (ARQConstants.registryFunctions) via NodeFmtLib

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1258:
---

Raised as a regression against 3.1.0 where this works. See [3.1.1 RC2 
vote|https://lists.apache.org/thread.html/f70071baeb37dc9b105d41ddb9080415ecf476172b2588d53640dae7@%3Cdev.jena.apache.org%3E].




> Context key is null (ARQConstants.registryFunctions) via NodeFmtLib
> ---
>
> Key: JENA-1258
> URL: https://issues.apache.org/jira/browse/JENA-1258
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.1.1
>    Reporter: Stian Soiland-Reyes
>
> This small test, with no ARQ.init(), causes a problem in initializers:
> {code}
> @Test
> public void testName() throws Exception {
> Node node = NodeFactory.createLiteral("Hello world", "en");
> assertEquals("\"Hello world\"@en", NodeFmtLib.str(node));
> }
> {code}
> It fails with:
> {code}
> java.lang.ExceptionInInitializerError
> at org.apache.jena.riot.out.NodeFmtLib.(NodeFmtLib.java:55)
> at org.apache.commons.rdf.jena.TestNodeStuff.testName(TestNodeStuff.java:15)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.jena.sparql.ARQException: Context key is null
> at org.apache.jena.sparql.util.Context._put(Context.java:102)
> at org.apache.jena.sparql.util.Context.set(Context.java:94)
> at 
> org.apache.jena.sparql.function.FunctionRegistry.set(FunctionRegistry.java:74)
> at 
> org.apache.jena.sparql.function.FunctionRegistry.init(FunctionRegistry.java:48)
> at org.apache.jena.query.ARQ.init(ARQ.java:592)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117)
> at org.apache.jena.sparql.ARQConstants.(ARQConstants.java:35)
> ... 25 more
> {code}
> closer debugging reveals that it is trying to set a context with the static 
> {{ARQConstants.registryFunctions}} which is still null:
> {code}
> Thread [main] (Suspended (breakpoint at line 102 in Context)) 
>   owns: Object  (id=65)   
>   owns: Class (org.apache.jena.system.JenaSystem) (id=61)  
>   owns: Object  (id=66)   
>   Context._put(Symbol, Object) line: 102  
>   Context.set(Symbol, Object) line: 94
>   FunctionRegistry.set(Context, FunctionRegistry) line: 74

[jira] [Created] (JENA-1258) Context key is null (ARQConstants.registryFunctions) via NodeFmtLib

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created JENA-1258:
-

 Summary: Context key is null (ARQConstants.registryFunctions) via 
NodeFmtLib
 Key: JENA-1258
 URL: https://issues.apache.org/jira/browse/JENA-1258
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ
Affects Versions: Jena 3.1.1
Reporter: Stian Soiland-Reyes


This small test, with no ARQ.init(), causes a problem in initializers:

{code}
@Test
public void testName() throws Exception {
Node node = NodeFactory.createLiteral("Hello world", "en");
assertEquals("\"Hello world\"@en", NodeFmtLib.str(node));
}
{code}

It fails with:

{code}


java.lang.ExceptionInInitializerError
at org.apache.jena.riot.out.NodeFmtLib.(NodeFmtLib.java:55)
at org.apache.commons.rdf.jena.TestNodeStuff.testName(TestNodeStuff.java:15)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.apache.jena.sparql.ARQException: Context key is null
at org.apache.jena.sparql.util.Context._put(Context.java:102)
at org.apache.jena.sparql.util.Context.set(Context.java:94)
at 
org.apache.jena.sparql.function.FunctionRegistry.set(FunctionRegistry.java:74)
at 
org.apache.jena.sparql.function.FunctionRegistry.init(FunctionRegistry.java:48)
at org.apache.jena.query.ARQ.init(ARQ.java:592)
at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194)
at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171)
at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117)
at org.apache.jena.sparql.ARQConstants.(ARQConstants.java:35)
... 25 more
{code}

closer debugging reveals that it is trying to set a context with the static 
{{ARQConstants.registryFunctions}} which is still null:

{code}
Thread [main] (Suspended (breakpoint at line 102 in Context))   
owns: Object  (id=65)   
owns: Class (org.apache.jena.system.JenaSystem) (id=61)  
owns: Object  (id=66)   
Context._put(Symbol, Object) line: 102  
Context.set(Symbol, Object) line: 94
FunctionRegistry.set(Context, FunctionRegistry) line: 74
FunctionRegistry.init() line: 48
ARQ.init() line: 592
InitARQ.start() line: 29
JenaSystem.lambda$init$2(JenaSubsystemLifecycle) line: 119  
2009221452.accept(Object) line: not available   
ArrayList.forEach(Consumer) line: 1249
JenaSystem.forEach(Consumer, 
Comparator) line: 194  
JenaSystem.forEach(Consumer) line: 171  
JenaSystem.init() line: 117 
ARQConstants.() line: 35
NodeFmtLib.() line: 55  
TestNodeStuff.testName() line: 17   
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not 
available [native method]  
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62  
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 4

Re: [VOTE] Release Apache jena 3.1.1 (2nd)

[Stian Soiland-Reyes]

I'll change my vote to a -0 as an ARQ.init(); is sufficient to fix it
for me. Nevertheless, not the kind of bug I would expect from a patch
update..

On 7 November 2016 at 00:25, Stian Soiland-Reyes  wrote:
> My problem seems to be with early access of NodeFactory and then
> org.apache.jena.riot.out.NodeFmtLib, e.g.
>
> @Test
> public void testName() throws Exception {
> Node node = NodeFactory.createLiteral("Hello world", "en");
> assertEquals("\"Hello world\"@en", NodeFmtLib.str(node));
> }
>
> Fails with:
>
> java.lang.ExceptionInInitializerError
> at org.apache.jena.riot.out.NodeFmtLib.(NodeFmtLib.java:55)
> at org.apache.commons.rdf.jena.TestNodeStuff.testName(TestNodeStuff.java:15)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.jena.sparql.ARQException: Context key is null
> at org.apache.jena.sparql.util.Context._put(Context.java:102)
> at org.apache.jena.sparql.util.Context.set(Context.java:94)
> at 
> org.apache.jena.sparql.function.FunctionRegistry.set(FunctionRegistry.java:74)
> at 
> org.apache.jena.sparql.function.FunctionRegistry.init(FunctionRegistry.java:48)
> at org.apache.jena.query.ARQ.init(ARQ.java:592)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117)
> at org.apache.jena.sparql.ARQConstants.(ARQConstants.java:35)
> ... 25 more
>
>
>
> On 7 November 2016 at 00:05, Stian Soiland-Reyes  wrote:
>> Thanks for putting together a 3.1.1 RC!
>>
>>
>> I'm afraid my vote is:
>>
>> -1 (non-binding)
>>
>> because of broken initializers and confusing LICENSE in source archive.
>>
>>
>> Checked:
>>
>> + GPG signatures
>> + source zip matches git commit; adds only (empty) DEPENDENCIES and
>> dependency-reduced-pom.xml
>> - Hashes - you didn't provide dist svn revision or its sha1 hashes,
>> I'll assume rev 16841
>> - repository JARs/POMs; broken initializers?
>> - LICENSE; confusing, see below
>> 0 NOTICE; see below
>> +1 binaries/apache-jena-3.1.1.tar.gz riot tested with json-ld
>> +1 binaries/apache-jena-fuseki-2.4.1.tar.gz tested with tdb, json-ld
>> upload and sparql
>> +1 mvn install -DskipTests=true
>> +1 mvn clean install (50 minutes!)
>> -1 outdated jackson
>> -1 wrong semantic versioning
>>
>>
>> I am failing this RC as I was unable to use the build artifacts from
>> Commons RDF 0.3.0-SNAPSHOT (master), which works fin

Re: [VOTE] Release Apache jena 3.1.1 (2nd)

[Stian Soiland-Reyes]

My problem seems to be with early access of NodeFactory and then
org.apache.jena.riot.out.NodeFmtLib, e.g.

@Test
public void testName() throws Exception {
Node node = NodeFactory.createLiteral("Hello world", "en");
assertEquals("\"Hello world\"@en", NodeFmtLib.str(node));
}

Fails with:

java.lang.ExceptionInInitializerError
at org.apache.jena.riot.out.NodeFmtLib.(NodeFmtLib.java:55)
at org.apache.commons.rdf.jena.TestNodeStuff.testName(TestNodeStuff.java:15)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.apache.jena.sparql.ARQException: Context key is null
at org.apache.jena.sparql.util.Context._put(Context.java:102)
at org.apache.jena.sparql.util.Context.set(Context.java:94)
at 
org.apache.jena.sparql.function.FunctionRegistry.set(FunctionRegistry.java:74)
at 
org.apache.jena.sparql.function.FunctionRegistry.init(FunctionRegistry.java:48)
at org.apache.jena.query.ARQ.init(ARQ.java:592)
at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194)
at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171)
at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117)
at org.apache.jena.sparql.ARQConstants.(ARQConstants.java:35)
... 25 more



On 7 November 2016 at 00:05, Stian Soiland-Reyes  wrote:
> Thanks for putting together a 3.1.1 RC!
>
>
> I'm afraid my vote is:
>
> -1 (non-binding)
>
> because of broken initializers and confusing LICENSE in source archive.
>
>
> Checked:
>
> + GPG signatures
> + source zip matches git commit; adds only (empty) DEPENDENCIES and
> dependency-reduced-pom.xml
> - Hashes - you didn't provide dist svn revision or its sha1 hashes,
> I'll assume rev 16841
> - repository JARs/POMs; broken initializers?
> - LICENSE; confusing, see below
> 0 NOTICE; see below
> +1 binaries/apache-jena-3.1.1.tar.gz riot tested with json-ld
> +1 binaries/apache-jena-fuseki-2.4.1.tar.gz tested with tdb, json-ld
> upload and sparql
> +1 mvn install -DskipTests=true
> +1 mvn clean install (50 minutes!)
> -1 outdated jackson
> -1 wrong semantic versioning
>
>
> I am failing this RC as I was unable to use the build artifacts from
> Commons RDF 0.3.0-SNAPSHOT (master), which works fine with Jena 3.1.0.
>
> This seems to be the case both with jena-osgi or with apache-jena-libs
> 
>
> To replicate, try do "mvn clean install -l api,simple,jena" in
> https://github.com/stain/incubator-commonsrdf/tree/jena-3.1.1-rc2
>
> Something wrong with the initializers or an internal dependency
> missing from a pom.xml somewhere..?  I'll see what I can figure out
> and raise in JIRA.
>
>
> JSON-LD is working, however in jena-parent/pom.xm
>
>  
>  2.6.3
>
> but the newer jsonld-java 0.8.4 (claims to) need  jackson 2.7.4:
> https://github.com/jsonld-java/jsonld-java/blob/v0.8.3/pom.xml#L44
>
> This might break u

Re: [VOTE] Release Apache jena 3.1.1 (2nd)

[Stian Soiland-Reyes]

s:httpCore  4.2.5 -> 4.4.4
>
>   com.jayway.awaitility:awaitility1.6.4 -> 1.7.0
>   com.spatial4j:spatial4j 0.4.1 -> 0.5
>   org.slf4j:* 1.7.20 -> 1.7.21
>   commons-codec:commons-codec 1.9 -> 1.10
>   org.apache.commons:commons-collections4 4.0 -> 4.1
>   org.apache.commons:commons-csv  1.0 -> 1.3
>   org.apache.commons:commons-lang33.3.2 -> 3.4
>   org.apache.thrift:libthrift 0.9.2 -> 0.9.3
>   org.apache.mrunit:mrunit1.0.0 -> 1.1.0
>   com.github.rvesse:airline   2.1.0 -> 2.1.1
>
>
> Key features of the release:
>
> * Improve JSON-LD output
>  JENA-1208 - François-Paul Servant
> http://jena.staging.apache.org/documentation/io/rdf-output.html#json-ld
>
> * Completed F&O XPath3 functions
>   JENA-508 - Alessandro Seganti
>
> * ComplexPhraseQueryParser
>  JENA-1180 - Andrew Dolby
>
> * Additional vocabularies (DCAT, VoID, ROV, ORG)
>   JENA-1206 - Bart Hanssens
>
> * Improvement to the Fuseki service script for RHEL/Centos 6.
>   JENA-1219 - Dan Pritts
>
> * ORDER BY now cancelable.
>
> * Txn : a highlevel API for working with transactions
> http://jena.staging.apache.org/documentation/txn/txn.html
>
> * Embedded Fuseki
> http://jena.staging.apache.org/documentation/fuseki2/fuseki-embedded.html
>
> * Property path speed ups (JENA-1195)
>
> * Upgrade to Apache HttpClient v4.3 API
>  => auth changes cause API changes.
>
>
> Everyone, not just committers, is invited to test and vote.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachejena-1015/
>
> Proposed dist/ area:
>  https://dist.apache.org/repos/dist/dev/jena/
>
> Keys:
>  https://svn.apache.org/repos/asf/jena/dist/KEYS
>  ** NB signing key has changed.
>
>
> Git commit (browser URL):
>  https://git-wip-us.apache.org/repos/asf/jena/commit/f7b3c416
>
> Git Commit Hash:
>  f7b3c416328bba4b8044e4ea8ad80e09ac51d720
>
> Git Commit Tag:
>  jena-3.1.1-rc2
>
> Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
> This vote will be open to at least
>
>  Monday, 7 Nov 2016, 23:59 UTC
>
> If you expect to check the release but the 72 hour limit does not work
> for you, please email within the schedule above with an expected time
> and we can extend the vote period.
>
> Thanks,
>
>  Andy
>
> Checking needed:
>
> + does everything work on Linux?
> + does everything work on MS Windows?
> + does everything work on OS X?
> + are the GPG signatures fine?
> + are the checksums correct?
> + is there a source archive?
> + can the source archive really be built?
> + is there a correct LICENSE and NOTICE file in each artifact
>(both source and binary artifacts)?
> + does the NOTICE file contain all necessary attributions?
> + have any licenses of dependencies changed due to upgrades?
> if so have LICENSE and NOTICE been upgraded appropriately?
> + does the tag/commit in the SCM contain reproducible sources?



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Re: Graph on Cassandra

[Stian Soiland-Reyes]

approach that makes sense
>>>>>>> there.
>>>>>>>
>>>>>>> ---
>>>>>>> A. Soroka
>>>>>>> The University of Virginia Library
>>>>>>>
>>>>>>> On Oct 17, 2016, at 12:20 PM, Andy Seaborne  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> IIRC It stores CBDs indexed by subject so it is the "other" model to
>>>>>>>>
>>>>>>>> Rya.  Better for LDP (??).
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> Andy
>>>>>>>>
>>>>>>>> On 17/10/16 15:41, A. Soroka wrote:
>>>>>>>>
>>>>>>>> There's also:
>>>>>>>>>
>>>>>>>>> https://github.com/cumulusrdf/cumulusrdf
>>>>>>>>>
>>>>>>>>> in a similar vein (RDF over Cassandra). Not sure what kind of
>>>>>>>>>
>>>>>>>>> particular uses it expects to support.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>> ---
>>>>>>>>> A. Soroka
>>>>>>>>> The University of Virginia Library
>>>>>>>>>
>>>>>>>>> On Oct 17, 2016, at 7:02 AM, Andy Seaborne  wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Claude,
>>>>>>>>>>
>>>>>>>>>> There is certainly interest from me.
>>>>>>>>>>
>>>>>>>>>> What the best thing to do depends on various factors.  By putting
>>>>>>>>>> it
>>>>>>>>>>
>>>>>>>>>> in extras I presume you mean it gets added to the release?  That is
>>>>>>>>>
>>>>>>>> not the
>>>>>> only way forward.
>>>>>>
>>>>>>
>>>>>>> An important aspect of Apache is "Community over code" - will there
>>>>>>>>>>
>>>>>>>>>> be a community around this code?  Is that community the same, or
>>>>>>>>>
>>>>>>>> significant overlap, as the Jena community?
>>>>>>
>>>>>>
>>>>>>> There are various reasons for wanting RDF over a column store -
>>>>>>>>>>
>>>>>>>>>> which use cases are the most important for this work?
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>> They lead to different ways of using Cassandra. For example,
>>>>>>>>>>
>>>>>>>>>> Rya(incubating) uses Accumulo tables as indexes, and partial scans
>>>>>>>>> of
>>>>>>>>>
>>>>>>>> the
>>>>>> table is streaming.  Other systems try to use the columns for
>>>>>> properties,
>>>>>> possibly more useful for LDP style than SPARQL.
>>>>>>
>>>>>>
>>>>>>>   Andy
>>>>>>>>>>
>>>>>>>>>> On 15/10/16 18:38, Claude Warren wrote:
>>>>>>>>>>
>>>>>>>>>> Howdy,
>>>>>>>>>>>
>>>>>>>>>>> We have a project at work that is implementing Jena Graph on
>>>>>>>>>>>
>>>>>>>>>>> Cassandra.  I
>>>>>>>>>>
>>>>>>>>>
>>>>>> am wondering if there is enough interest here to accept it as a
>>>>>>>
>>>>>>>> contribution.  I was thinking that it might fit in the Extras
>>>>>>>>>>>
>>>>>>>>>>> category.
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>> I can not promise release of the code yet as I have to present it
>>>>>>>>>>>
>>>>>>>>>>> to our
>>>>>>>>>>
>>>>>>>>>
>>>>>> internal Intellectual Property group first.
>>>>>>>
>>>>>>>>
>>>>>>>>>>> Thoughts?
>>>>>>>>>>>
>>>>>>>>>>> Claude
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Re: Graph on Cassandra

[Stian Soiland-Reyes]

Do you think it would make sense to do a Cassandra  Commons RDF API binding
for Graph or Dataset..? Or would that be too high level?

The streaming part would fit well there I think.

Commons RDF 0.3.0 is under vote now, adding Quad, Dataset and "RDF" as the
factory interface.

https://commonsrdf.incubator.apache.org/apidocs/index.html?org/apache/commons/rdf/api/package-summary.html

But it could make more sense as a Jena DatasetGraph so it can be used by
sparql queries etc. (And then exposed as Commons RDF Jena bindings if one
so wanted)

On 31 Oct 2016 1:41 pm, "Claude Warren"  wrote:

> Andy,
>
> This seems like a good approach but does not appear to be in the Jena code
> base, which I suppose is your comment about an approach to developing work.
>
> Does it make sense to create git clones that contain the new work?  Or
> perhaps branches?
>
> Do you have a suggestion or direction you would like to see this go?
>
> Claude
>
>
>
> On Fri, Oct 28, 2016 at 2:35 PM, Andy Seaborne  wrote:
>
> > Claude,
> >
> > These may help:
> >
> > I have been thinking about an interface that is more oriented to the
> > storage than the full DatasetGraph.
> >
> > StorageRDF breaks down all the operations into those on the default graph
> > and those on named graphs.  For just a graph, simply ignore the named
> graph
> > operations.
> >
> > https://github.com/afs/AFS-Dev/blob/master/src/main/java/pro
> > jects/dsg2/storage/StorageRDF.java
> >
> > There is an adapter to the DatasetGraph hierarchy (which is needed for
> > SPARQL):
> >
> > https://github.com/afs/AFS-Dev/blob/master/src/main/java/pro
> > jects/dsg2/DatasetGraphStorage.java
> >
> > If you want to only use existing classes, DatasetGraphTriplesQuads is the
> > place to start - used by TIM and TDB - yuo can implement without needing
> > quads/named graphs. Again, simply ignore (throw
> > UnsupportedOperationException for the named graph calls).
> >
> > Going the graph route could lead to rework later on for any kind of
> > performance issues because find(S,P,O) is so narrow and precludes union
> > default graph except by brute force.  DatasetGraph work with the SPARQL
> > execution engine.
> >
> > We still need to discuss how best to approach developing work - it should
> > not get sucked up by the release cycle.
> >
> > Andy
> >
> >
> > On 26/10/16 19:21, Claude Warren wrote:
> >
> >> My plan is to start with a Graph implementation.  We expect to write 3
> >> tables: SPO, POS, OPS (I think).  Currently we don't have an easy way to
> >> handle find( ANY, ANY, ANY) so I suspect we will just start with
> >> permitting
> >> a column scan on Cassandra.
> >>
> >> I have not looked at DynamoDB but as I recall there are significant
> >> differences under the hood.
> >>
> >> I expect that we will move on to a custom model or query engine to get
> the
> >> best performance but that is not what we are planning for the first cut.
> >>
> >> I am still waiting for management approval to do this at work 
> >> sometimes it takes longer to get the paperwork done than it does to
> design
> >> the thing.
> >>
> >>
> >> Claude
> >>
> >> On Mon, Oct 17, 2016 at 6:39 PM, Paul Houle 
> >> wrote:
> >>
> >> I like DynamoDB as a target for this sort of thing.  There are many
> >>> tasks which are small-scale yet critical where it would otherwise be
> >>> hard to provide a distributed and reliable database.  Put that together
> >>> with Lambda,  which does the same for computation,  and you are cooking
> >>> with gas.
> >>>
> >>> I wrote a 1-1 translation of DynamoDB documents to RDF that I use
> >>> throughout an application;  the code is DynamoDB idiomatic in every
> way,
> >>>  just the application reads and writes (a constrained set of) RDF
> >>> documents.
> >>>
> >>> Right now I dump the documents from the DynamoDB system into a triple
> >>> store when I want a panoptic view,  but with a distributed graph like
> >>> that would mean being able to run SPARQL queries against DynamoDB
> >>> directly.
> >>>
> >>> There are many products in the same family as Cassandra and DynamoDB
> and
> >>> it would be good to think through the math so we can approach them all
> >>> in a similar way.
> >>>
> >>> --
> >>>   Paul Houle
> >>>   paul.ho...@ontology2.com
> >>>
> >>> On Mon, Oct 17, 2016, at 12:31 PM, A. Soroka wrote:
> >>>
>  Yep,
> 
>  http://iswc2011.semanticweb.org/fileadmin/iswc/Papers/
> 
> >>> Workshops/SSWS/Ladwig-et-all-SSWS2011.pdf
> >>>
> 
>  indicates that they are indexing by subject. As someone who has
>  implemented LDP, that is definitely the approach that makes sense
> there.
> 
>  ---
>  A. Soroka
>  The University of Virginia Library
> 
>  On Oct 17, 2016, at 12:20 PM, Andy Seaborne  wrote:
> >
> > IIRC It stores CBDs indexed by subject so it is the "other" model to
> >
>  Rya.  Better for LDP (??).
> >>>
> 
> > Andy
> >
> > On 17/10/16 15:41, A. Soroka wrote:
> >
> >>

[jira] [Commented] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1169:
---

I think it's just in README as it's a good guidance for downstream - strangely 
we have no legal requirement to inform our downstream users that the item 
contains cryptography functionality at all.. So it should not go in NOTICE 
(which is legally required to be propagated).  Also NOTICE is hard to modify - 
but it's often easy to remove the crypto functionality or item.


BTW - here's the step-by-step [Taverna Crypto 
review|https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review]

I agree Taverna Language was a bit uncertain as it does not have code that is 
designed to work with encryption functionality (just with encryption items) - 
it is listed because it makes a shaded JAR that include encryption items:

> The shaded JAR of taverna-tavlang-tool include Apache HttpComponents Core and 
> Client (ECCN classified on https://www.apache.org/licenses/exports/), which 
> can initiate encrypted https:// connections using Java Secure Socket 
> Extension (JSSE).

Although we didn't at the time put that in dist.apache.org, we might do so in 
the future without having to send another registration email. And as users 
building it would get that JAR I thought it would be good to let them know in 
the README. 


Jena has just a single git repository, so that would be the one that would be 
reported - but as far as I can tell don't include any code designed to work 
with encryption functionality, (just code using dependencies that happen to be 
encryption items) except perhaps Fuseki's integration with Shiro, which I am 
not sure but could be configured to use encryption for authentication?

Agree on the way Andy suggest README updates, so no need to honour my pull 
request change of the top-level README

> Is Jena US Export classified due to encryption in dependencies?
> ---
>
> Key: JENA-1169
> URL: https://issues.apache.org/jira/browse/JENA-1169
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Build
>Reporter: Stian Soiland-Reyes
>
> Hi - apologies for finding this..
> I just noticed  on 
> http://www.apache.org/licenses/exports/   
> includes US export classified tools from ASF:
> Apache HttpComponents Core 4.0 and later
> Apache HttpComponents Client 4.0 and later
> Apache Hadoop 17.0 and later
> See also:
> http://www.apache.org/dev/crypto.html#faq-manyproducts
> We redistribute Apache HTTP Components in the Jena and Fuseki binary 
> distributions. We don't distribute Hadoop - we only link to it from Elephas.
> Reading ASF's FAQ it is not clear if we would need to be listed just from 
> having a  on such a classified item.
> Would we therefore also need to also declare Jena as classified? Or is the 
> transitivity broken because Jena only use the encryption (e.g. access 
> https:// JSON-LD contexts)? 
> (This transitivity thing could mean anyone in the US distributing software 
> using Jena would be US Export regulated. I hope I am wrong.. worth checking 
> with LEGAL I think)
> BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
> dependency:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E
> h2. Draft eccnmatrix.xml additions
> To be added to 
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
> and then published to http://www.apache.org/licenses/exports/
> See http://www.apache.org/dev/crypto.html#sources
> {code:xml}
>  http://jena.apache.org";>
>   Apache Jena
>   Andy Seaborne
>   
> Apache Jena
> 
>   development
>   5D002
>href="https://git-wip-us.apache.org/repos/asf/jena.git";>
> ASF
> Use Apache HTTPComponents Client
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>href="http://archive.apache.org/dist/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
> 
> 
>   2.7.0-incubating and later
>   5D002
>   http://archive.apache.org/dist/jena/source/";>
> ASF
> Use Apache HTTPComponents Client
>   
>   http://archive.apache.org/dist/jena/binaries/

Re: Export registration

[Stian Soiland-Reyes]

http://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items
says

> Is the item designed to use cryptography or does it contain cryptography?

> Almost all items controlled under Category 5, Part 2 of the EAR are 
> controlled because they include encryption functionality. Items may be 
> controlled as encryption items even if the encryption is actually performed 
> by the operating system, an external library, a third-party product or a 
> cryptographic processor. If an item uses encryption functionality, whether or 
> not the code that performs the encryption is included with the item, then BIS 
> evaluates the item based on the encryption functionality it uses.

Similarly, if the item includes encryption functionality, even if the
encryption functionality is not used by the item, then BIS evaluates
the item based on the included encryption functionality.


So "include encryption functionality" would be the case for the binary
dists that embed Jetty, etc.

If it is not included (as in the source code) then it's evaluated on
which encryption functionality that is used - which would not be
directly used by Jena's source code, but by HTTP Client's support for
HTTPS etc. (We only use the HTTP Client encryption ITEM rather than
the HTTP Client encryption FUNCTIONALITY). So I think you are right in
the approach you suggest.



On 30 October 2016 at 13:56, Andy Seaborne  wrote:
> Jena does not implement any cryptographic but we do bundle dependencies that
> include such software in the binary distributions for HTTPS and for web app
> security (Shiro).
>
> Plan:
>
> 1/ Include a "Cryptographic Software Notice" in each of the binary
> distribution README files.
>
> apache-jena/dist/README
> jena-fuseki2/apache-jena-fuseki/README
> jena-fuseki1/apache-jena-fuseki/README
>
> This part is Apache-required and not part of the US export registration
> process.
>
> The software bundled concerned is
>   Apache HttpClient
>   Apache HttpComponents Core
>   Eclipse Jetty
>   Apache Shiro
>
> PR#187
>
> 2/ Register a product
>
> NB "version" has a specific means, more like "usage"
>
> "Apache Jena (distribution)"
>   Versions: development
> [for the snapshot maven repo]
> binary distribution
> [for the binaries and release maven repo]
>
> and send required email to the required US gov organisations and Apache
> lists.
>
> 
>
> I thought about 3 products (apache-jena, fuseki1, fuseki2). For stability,
> the links ended up to the gernal area of repo or archives (as other projects
> also have it) so 3 products did not make anything better.
>
> I also looked at various other projects - things are not uniform. Theer are
> cases of "over register" where the crypto notice in the code base README.
> That's unhelpful when the project itself does not provide crypto software
> and wrong when the source-release gets made (it goes not contain any such
> software). Like NOTICE, being minimal seemed more in the spirit of things.
>
> Andy
>
> [1] http://www.apache.org/dev/crypto.html
> [2] http://www.apache.org/licenses/exports/



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Re: Rising the bar on us...@jena.apache.org

[Stian Soiland-Reyes]

OK, I think that is a good idea to get in touch with the teachers; perhaps
so they can give us an advance notice and we can understand what their
course is meant to teach. So a more friendly request for the teachers to
get in touch (or we ask directly the name/email of their teacher), but
without the "so you stop irritating us" bit :-). Presumably the teachers
dont want us to do the assignment for their students!

There could even be opportunities to do like a webinar or video with a
short Jena intro, there are is probably some material from Elixir's Bring
Your Own Data training events and similar that we could link to; if the
teachers have better background materials and tutorials it can hopefully
reduce our email load.

On 23 Oct 2016 10:43 pm, "A. Soroka"  wrote:

> > Then there are the obvious school examples, which seem to ask us the
> actual assignment rather than Jena questions. It is fair for us to dodge
> those, but perhaps in a less hostile way.
>
> It seems to me that this is the entire question: there aren't really the
> kinds of problems Colin Maudry raised _except_ with these examples. And the
> messages that worry me are not the initial questions that amount to "please
> do my assignment" but the fact that helpful voices on the list give in
> response to such questions good advice and next steps which are repeatedly
> ignored.
>
> > I think we are friendly (perhaps sometimes too helpful!), but I wouldn't
> go to a "go away and talk to your teacher" route, but rather in general
> respond with what is expected of a good question and what the poster should
> try first.
>
> I'm not sure if this particular remark is in response to my suggestion,
> but just in case, I will clarify: I don't want to tell the students to go
> away, I want to tell them to ask their teacher(s) to contact Jena directly
> (instead of inadvertently and indirectly by giving assignments that show up
> immediately as questions on the user list), hopefully to help create a more
> appropriate kind of engagement for their students with the Jena community.
>
> ---
> A. Soroka
> The University of Virginia Library
>
> > On Oct 23, 2016, at 5:24 PM, Stian Soiland-Reyes 
> wrote:
> >
> > Agree to not go too aggressive in general, it could also strike down
> users
> > who like Jena as a tool (remember we have command lines and servers!) or
> > have been recommended Jena, but who have not before used Java as
> > programming language before. Here, tutorials and examples is what we
> should
> > point to.
> >
> > Then there are the obvious school examples, which seem to ask us the
> actual
> > assignment rather than Jena questions. It is fair for us to dodge those,
> > but perhaps in a less hostile way. Many students and researchers I have
> > interviewed in the Big Data community say they struggle to post their
> > questions on mailing lists for the tools they use, as they get hammered
> > down for basically not being geeky enough. Consequently they don't come
> > back when their skill sets have improved and they could potentially have
> > contributed back.
> >
> > Also remember that students have perhaps never before used a public
> mailing
> > list and already struggle to separate what is RDF, what is OWL, what is
> > Java, what is Jena, what is just a bug in their own code.
> >
> > I think we are friendly (perhaps sometimes too helpful!), but I wouldn't
> go
> > to a "go away and talk to your teacher" route, but rather in general
> > respond with what is expected of a good question and what the poster
> should
> > try first. Point to gist.github.com or similar as a way to paste code
> > rather than getting it in the abstract ("I tried setting the literal")
> > helps a lot.
> >
> > Also I think we can reply shorter (but friendly) as a bounce, rather
> than a
> > complete reply to help them with the more obvious assignment side. We can
> > point to tutorials for coding as well; Software Carpentry has many great
> > starting points.
> >
> > On 23 Oct 2016 7:43 pm, "Paul Houle"  wrote:
> >
> >> I find this thread disturbing.  Many people in the RDF community have
> >> worked a long time and it's just recently that the uptake has broadened
> >> (people are looking at JSON-LD and starting to understand what it means,
> >> not what any particular authority says that it means,  but what it
> >> actually means.)
> >>
> >> I do believe that problems should be made reproducable and as a group we
> >> could industrialize that.  For instance,  a test 

Re: Rising the bar on us...@jena.apache.org

[Stian Soiland-Reyes]

Agree to not go too aggressive in general, it could also strike down users
who like Jena as a tool (remember we have command lines and servers!) or
have been recommended Jena, but who have not before used Java as
programming language before. Here, tutorials and examples is what we should
point to.

Then there are the obvious school examples, which seem to ask us the actual
assignment rather than Jena questions. It is fair for us to dodge those,
but perhaps in a less hostile way. Many students and researchers I have
interviewed in the Big Data community say they struggle to post their
questions on mailing lists for the tools they use, as they get hammered
down for basically not being geeky enough. Consequently they don't come
back when their skill sets have improved and they could potentially have
contributed back.

Also remember that students have perhaps never before used a public mailing
list and already struggle to separate what is RDF, what is OWL, what is
Java, what is Jena, what is just a bug in their own code.

I think we are friendly (perhaps sometimes too helpful!), but I wouldn't go
to a "go away and talk to your teacher" route, but rather in general
respond with what is expected of a good question and what the poster should
try first. Point to gist.github.com or similar as a way to paste code
rather than getting it in the abstract ("I tried setting the literal")
helps a lot.

Also I think we can reply shorter (but friendly) as a bounce, rather than a
complete reply to help them with the more obvious assignment side. We can
point to tutorials for coding as well; Software Carpentry has many great
starting points.

On 23 Oct 2016 7:43 pm, "Paul Houle"  wrote:

> I find this thread disturbing.  Many people in the RDF community have
> worked a long time and it's just recently that the uptake has broadened
> (people are looking at JSON-LD and starting to understand what it means,
>  not what any particular authority says that it means,  but what it
> actually means.)
>
> I do believe that problems should be made reproducable and as a group we
> could industrialize that.  For instance,  a test project that can be
> forked in github would be a great place to put in a query,  put in a
> graph,  and then put in some rules at which point  they could ask good
> questions.
>
> I carefully read the answers to the bad questions because I am intensely
> curious about strange details in Jena that trip people up.
>
> --
>   Paul Houle
>   paul.ho...@ontology2.com
>
> On Sun, Oct 23, 2016, at 06:07 AM, Colin Maudry wrote:
> > Dear Jena developers,
> >
> > Upon Andy Seaborne’s suggestion, I would like to share with you a
> > concern we have with certain posts shared on us...@jena.apache.org.
> > In the last couple months, we have seen certain users repeatedly sending
> > questions that are either:
> >
> >   * hardly related to Jena and Fuseki
> >   * very basic questions about RDF or SPARQL
> >   * betraying the lack of common knowledge in Java programming and
> > coding good practice in general
> >
> > What’s worse, these users, in spite of repeated remarks, keep on being
> > very vague in their questions, requiring the most patient subscribers to
> > ask many questions just to obtain a decent understanding of the problem.
> > A problem that is, again, often not much related to Jena or Fuseki.
> >
> > As a subscriber, I’m tired of their consistent failure to propose clear
> > and concise questions and I wish the patient people who answer them
> > spend their mailing time on more interesting threads. I also fear it
> > makes certain subscribers silently go away because of this “noise”.
> >
> > I first thought of publicly complaining to these users, but I thought
> > that the managers of the Jena lists should discuss it and take the
> > appropriate measures.
> >
> > My suggestion is to:
> >
> >   * inform the subscribers of an upcoming enforcement of the publishing
> > rules (relevance, clearness, completeness, etc.)
> >   * stop answering the vague/off-topic/badly presented questions
> >   * if they insist, remind them the topic of the list and good practices
> > in problem reporting, and warn them of a possible ban.
> >
> > Thanks for your attention,
> >
> > Colin Maudry
> > https://twitter.com/CMaudry
> >
> > ​
>

Re: running TDB tests?

[Stian Soiland-Reyes]

+1 to remove any outdated bin-test/ scripts, they have confused me as well..

Test resources should ideally be in src/test/resources in Maven, and the
test can then use getClass().getResource*() to get it from class path
copying to a Files.createTempFile if needing a Path or File instance.

On 21 Oct 2016 6:13 pm, "A. Soroka"  wrote:

> Maybe better to prune them, since the knowledge will remain in VC?
>
> ---
> A. Soroka
> The University of Virginia Library
>
> > On Oct 21, 2016, at 12:06 PM, Andy Seaborne  wrote:
> >
> >
> > Several module have "testing/" directories.  They are for any one the
> test wants to work from files, including the W3C test manifest.
> >
> > bin-test/ are old scripts to help run helpers used during development. I
> doubt they work (cmd/classpath changes) but they do record knowledge.
> >
> >Andy
> >
> > On 21/10/16 15:38, A. Soroka wrote:
> >> Looking in TDB's source, I see folders bin-test and testing, which seem
> to contain testing scripts and manifests and data. I was wondering how to
> run these? I can't seem to find a place to begin. {grin}
> >>
> >> ---
> >> A. Soroka
> >> The University of Virginia Library
> >>
>
>

Re: tdbloader2 hex files

[Stian Soiland-Reyes]

Isn't numerical sorting a fair bit slower if you need to convert from
decimal to binary representation first? The algorithm for this is quite
convoluted and don't have fixed costs - until recently there was even a bug
on some platforms were a particular string caused an infinite loop. (But
that might have been to floating points :-)

Byte-by-byte comparison without unicode should be fairly fast.. but worth
checking if "sort" is a slowdown (I didn't think it was the slowest bit of
tdbloader2)

On 20 Oct 2016 10:01 pm, "A. Soroka"  wrote:

> I've been tinkering with tdbloader2 and optimizing a use of it, and now
> I've got a question about the intermediate files created (data-quads.tmp
> and data-triples.tmp).
>
> They contain hexadecimal numbers that represent node IDs in tuples; the
> contents of the database to be build in tabular form. The TDB node IDs are
> 64 bit integers, if I remember correctly, and as I say, they are
> represented in these files as long hex strings. These data files are sorted
> before being packed into indexes, and that sort occurs by using plain old
> POSIX `sort`.
>
> If `sort` is the tool to be used (or at least the default, since it can be
> aliased out if appropriate) wouldn't it make more sense for those IDs to be
> decimal-radix integers, so that numeric comparison (which is often faster
> because it avoids locale machinery; even 'C' locale has some work involved)
> could be used in `sort`? To my knowledge, most `sort`s out there won't
> handle hex with numeric comparison-- only string comparison.
>
> Or am I (as I often am) missing something about how those numbers get
> used? Obviously, decimal versions of the IDs would be darn big numbers and
> less readable, but if that is the concern, would there be any objection to
> providing a switch on the utility to choose which radix and comparison
> function to use?
>
> ---
> A. Soroka
> The University of Virginia Library
>
>

Re: RDF Patch - experiences suggesting changes

[Stian Soiland-Reyes]

Obviously that would be the case for the flat file (no transactions) and
order of any transactions.

So if that is the case also *inside* a transaction, then you are
effectively doing suboperations with a new transactional state per line in
the transaction.

How about restricting transactions to always have the order DDD ..?
That would help on reversibility as well as you can't then remove triples
added in the same transaction. (Reversibility is just to swap A/D blocks).

Perhaps DDD ordering could be a restriction only for Reversible
transactions as it could prevent a more "naive" log approach to be used
with transactions..?

On 19 Oct 2016 1:40 pm, "Rob Vesse"  wrote:

> I am pretty sure that the intent is that a patch must be read in linear
> order i.e. It is not designed for parallel processing
>
> On 19/10/2016 11:34, "Stian Soiland-Reyes"  wrote:
>
> I had a quick go, and the penalty from gzip with using expanded forms
> without "R" was negligible (~ 0.1%, a bit higher with no prefixes). It
> also means you can't process the RDF Patch in a parallel way without
> preprocessing.  (Same for prefixes).
>
> Using "R" could also restrict possible compression pattern, for
> instance in :
>
> A <http://example.com/thingie15>
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> <http://schema.org/Person> .
> A <http://example.com/thingie15>
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> <http://schema.org/Person> .
>
> a good compression algorithm might recognize patterns in here like:
>
>  .\nA <http://example.com/thingie
> > <http://www.w3.org/
> #type> <http://schema.org/
>
>
> Using "R" would restrict possible patterns - betting on it recognizing
> "> .\nA R R" (which sometimes would work well).
>
>
>
> Can RDF Patch items within a transaction be considered in any order
> (first all the DELETEs, then all the ADDs), or do they have to be
> played back linearly?
>
>
> On 19 October 2016 at 10:57, Rob Vesse  wrote:
> > Yes but ANY is a form of lossy compression. You lost the actual
> details of what was removed. Also it can only be used for removals and
> yields no benefit for additions.
> >
> >  On the other hand REPEAT is lossless compression.
> >
> >  However if you apply a general-purpose compression like gzip on top
> of the patch you probably get just as good compression without needing any
> special tokens. In my experience repeat is more useful in compact binary
> formats where you can use fewer bytes to encode it then either the term
> itself or a reference to the term in some lookup table.
> >
> > On 14/10/2016 17:09, "Andy Seaborne"  wrote:
> >
> > These two together seem a bit contradictory.  The advantage of
> ANY, with
> > versions, is that it is form of compression.
> >
> >
> >
> >
>
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
>
>
>
>
>

Re: RDF Patch - experiences suggesting changes

[Stian Soiland-Reyes]

I had a quick go, and the penalty from gzip with using expanded forms
without "R" was negligible (~ 0.1%, a bit higher with no prefixes). It
also means you can't process the RDF Patch in a parallel way without
preprocessing.  (Same for prefixes).

Using "R" could also restrict possible compression pattern, for instance in :

A <http://example.com/thingie15>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://schema.org/Person> .
A <http://example.com/thingie15>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://schema.org/Person> .

a good compression algorithm might recognize patterns in here like:

 .\nA <http://example.com/thingie
> <http://www.w3.org/
#type> <http://schema.org/


Using "R" would restrict possible patterns - betting on it recognizing
"> .\nA R R" (which sometimes would work well).



Can RDF Patch items within a transaction be considered in any order
(first all the DELETEs, then all the ADDs), or do they have to be
played back linearly?


On 19 October 2016 at 10:57, Rob Vesse  wrote:
> Yes but ANY is a form of lossy compression. You lost the actual details of 
> what was removed. Also it can only be used for removals and yields no benefit 
> for additions.
>
>  On the other hand REPEAT is lossless compression.
>
>  However if you apply a general-purpose compression like gzip on top of the 
> patch you probably get just as good compression without needing any special 
> tokens. In my experience repeat is more useful in compact binary formats 
> where you can use fewer bytes to encode it then either the term itself or a 
> reference to the term in some lookup table.
>
> On 14/10/2016 17:09, "Andy Seaborne"  wrote:
>
>     These two together seem a bit contradictory.  The advantage of ANY, with
> versions, is that it is form of compression.
>
>
>
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

[jira] [Commented] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1169:
---

Yes, there's no legal requirement for it to be in a file called README - so you 
could just as well move it to EXPORTING.md or something and link to that from 
README. 

Now that we've got BUILD.md and CONTRIBUTING.md it should not need much to 
improve Jena's README.md

For inspiration here's one example where I don't feel the Export text is too 
intimidating: 
https://github.com/apache/incubator-taverna-language#apache-taverna-language

> Is Jena US Export classified due to encryption in dependencies?
> ---
>
> Key: JENA-1169
> URL: https://issues.apache.org/jira/browse/JENA-1169
> Project: Apache Jena
>  Issue Type: Bug
>      Components: Build
>Reporter: Stian Soiland-Reyes
>
> Hi - apologies for finding this..
> I just noticed  on 
> http://www.apache.org/licenses/exports/   
> includes US export classified tools from ASF:
> Apache HttpComponents Core 4.0 and later
> Apache HttpComponents Client 4.0 and later
> Apache Hadoop 17.0 and later
> See also:
> http://www.apache.org/dev/crypto.html#faq-manyproducts
> We redistribute Apache HTTP Components in the Jena and Fuseki binary 
> distributions. We don't distribute Hadoop - we only link to it from Elephas.
> Reading ASF's FAQ it is not clear if we would need to be listed just from 
> having a  on such a classified item.
> Would we therefore also need to also declare Jena as classified? Or is the 
> transitivity broken because Jena only use the encryption (e.g. access 
> https:// JSON-LD contexts)? 
> (This transitivity thing could mean anyone in the US distributing software 
> using Jena would be US Export regulated. I hope I am wrong.. worth checking 
> with LEGAL I think)
> BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
> dependency:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E
> h2. Draft eccnmatrix.xml additions
> To be added to 
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
> and then published to http://www.apache.org/licenses/exports/
> See http://www.apache.org/dev/crypto.html#sources
> {code:xml}
>  http://jena.apache.org";>
>   Apache Jena
>   Andy Seaborne
>   
> Apache Jena
> 
>   development
>   5D002
>href="https://git-wip-us.apache.org/repos/asf/jena.git";>
> ASF
> Use Apache HTTPComponents Client
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>href="http://archive.apache.org/dist/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
> 
> 
>   2.7.0-incubating and later
>   5D002
>   http://archive.apache.org/dist/jena/source/";>
> ASF
> Use Apache HTTPComponents Client
>   
>   http://archive.apache.org/dist/jena/binaries/";>
> ASF
> Include Apache HTTPComponents Client
>   
> 
>   
>   
> Apache Jena Fuseki
> 
>   development
>   5D002
>href="https://git-wip-us.apache.org/repos/asf/jena.git";>
> ASF
> Use Apache HTTPComponents Client, Apache Shiro
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>href="http://archive.apache.org/dist/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>   http://archive.apache.org/dist/shiro/";>
> ASF
> Designed for use with Java Cryptography Extensions (JCE)
>   
> 
> 
>   0.2.1-incubating and later
>   5D002
>   http://archive.apache.org/dist/jena/source/";>
> ASF
> Use Apache HTTPComponents Client, Apache Shiro
>   
>   http://archive.apache.org/dist/jena/binaries/";>
> ASF
> Include Apache HTTPComponents, Apache Shiro, Apache Solr, 
> Jetty
>   
>href

Re: Jena integration for Commons RDF (JENA-1015, COMMONSRDF-35)

[Stian Soiland-Reyes]

Thanks!

Here are some of the other Commons RDF topics that would be good to
get feedback on:

https://lists.apache.org/list.html?d...@commons.apache.org:lte=1M:%5BRDF%5D

Some of these are design questions that would be good to clarify
before we release API changes.



On 29 September 2016 at 14:26, A. Soroka  wrote:
> Stian--
>
> I will look at this today, but even beforehand, I want to volunteer to help 
> in whatever way is useful to move this effort forward. I filed JENA-1015 
> because downstream projects on which I work would very much like to shift to 
> Commons as their RDF underpinning.
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Sep 29, 2016, at 6:23 AM, Stian Soiland-Reyes  wrote:
>>
>> I've proposed a "jena" integration module to Commons RDF, which I
>> think we should try to release as part of Commons RDF 0.3.0
>>
>> It's based on Andy's earlier integration on GitHub[1] (JENA-1015), but adds
>> support for Dataset, Quad (and generalized quad!), RDFParser.
>>
>>
>> The entry point would be the JenaRDFTermFactory [2] as well as the
>> experimental JenaRDFParser [3].0
>>
>> The JenaRDFTermFactory create Commons RDF instances backed by Jena, as
>> well as doing from/to conversions between the APIs.
>>
>> I've already tested this with the new RDF4j module, which shows that
>> you can transparently add Jena triple to RDF4J graph stores and vice
>> versa.
>>
>>
>> I wonder if Jena folks would be able to quickly review this for sanity
>> and design decisions?
>>
>>
>> Code: https://github.com/apache/incubator-commonsrdf/pull/23/files
>>
>> Javadoc: 
>> http://stain.github.io/incubator-commonsrdf/COMMONSRDF-35/org/apache/commons/rdf/jena/package-summary.html
>>
>>
>>
>>
>>
>>
>> [1] https://github.com/afs/commonsrdf-jena
>> [2] 
>> http://stain.github.io/incubator-commonsrdf/COMMONSRDF-35/org/apache/commons/rdf/jena/JenaRDFTermFactory.html
>> [3] 
>> http://stain.github.io/incubator-commonsrdf/COMMONSRDF-35/org/apache/commons/rdf/jena/experimental/JenaRDFParser.html
>>
>> --
>> Stian Soiland-Reyes
>> http://orcid.org/-0001-9842-9718
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Jena integration for Commons RDF (JENA-1015, COMMONSRDF-35)

[Stian Soiland-Reyes]

I've proposed a "jena" integration module to Commons RDF, which I
think we should try to release as part of Commons RDF 0.3.0

It's based on Andy's earlier integration on GitHub[1] (JENA-1015), but adds
support for Dataset, Quad (and generalized quad!), RDFParser.


The entry point would be the JenaRDFTermFactory [2] as well as the
experimental JenaRDFParser [3].0

The JenaRDFTermFactory create Commons RDF instances backed by Jena, as
well as doing from/to conversions between the APIs.

I've already tested this with the new RDF4j module, which shows that
you can transparently add Jena triple to RDF4J graph stores and vice
versa.


I wonder if Jena folks would be able to quickly review this for sanity
and design decisions?


Code: https://github.com/apache/incubator-commonsrdf/pull/23/files

Javadoc: 
http://stain.github.io/incubator-commonsrdf/COMMONSRDF-35/org/apache/commons/rdf/jena/package-summary.html






[1] https://github.com/afs/commonsrdf-jena
[2] 
http://stain.github.io/incubator-commonsrdf/COMMONSRDF-35/org/apache/commons/rdf/jena/JenaRDFTermFactory.html
[3] 
http://stain.github.io/incubator-commonsrdf/COMMONSRDF-35/org/apache/commons/rdf/jena/experimental/JenaRDFParser.html

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

Re: timing out big sorts

[Stian Soiland-Reyes]

I think you are right.. as a sorting an array would probably not be doing
any interruptible/blocking operations and the thread would keep sorting,
and so basically you would then need a Comparator that checks the thread
interruption status and bails out. :-)

So I guess Chris's suggestion is a good approach. Testing possible
performance improvements on big arrays with parallelSort would be separate
task, that can still use the same Comparator (but with a slightly different
exception pattern and would then need to avoid the non-thread-safe internal
counter).

On 15 Jul 2016 11:54 p.m., "Andy Seaborne"  wrote:

> On 15/07/16 15:10, Stian Soiland-Reyes wrote:
>
>> First of all the sorting could be sped up significantly on a
>> multi-core machine by using Java 8's:
>>
>> http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#parallelSort-T:A-
>>
>> (The speed-up can in some cases be much larger than the multiple of
>> the number of cores)
>>
>>
>> ..sadly the underlying ArraysParallelSortHelpers.FJObject.Sorter is
>> not publicly accessible, because then its ForkJoinTask could be used
>> to cancel an ongoing sort.
>>
>> What about instead using a FutureTask which you cancel with
>> future.cancel(true),
>>
>
>
> http://stackoverflow.com/questions/11158454/future-task-of-executorservice-not-truly-cancelling
>
> the task would just call Arrays.parallelSort().
>>
>
> and may not get cancelled :-(
>
>
>> The array might be in a weird state if you cancel/interrupt mid-sort
>> (e.g. duplicate values) - but on cancelling you can clear/forget the
>> array. And by keeping the array sorting in a separate thread you won't
>> be interrupting something within Jena's internal (e.g. a TDB index
>> update)
>>
>>
>>
>> On 15 July 2016 at 12:08, Chris Dollin 
>> wrote:
>>
>>> Dear All
>>>
>>> When a query with an ORDER BY is cancelled, the component
>>> Arrays.sort() that sorts the chunk(s) of the result
>>> bindings runs to completion before the cancel finishes.
>>> [See QueryIterSort and SortedDataBag.]
>>>
>>> For a large result set, this results in a long wait
>>> before the cancelled request finally finishes. This
>>> can be inconvenient.
>>>
>>> The cancel request can be sneaked into the sort by
>>> way of the comparator [1] and adding an instance
>>> variable `cancelled` to SortedDataBag, set `true`
>>> from QueryIterSort.requestCancel(). The comparator
>>> checks `cancelled` and if it has become `true`
>>> throws an exception, which is then caught outside
>>> the call to Arrays.sort(), abandoning the sort.
>>> See attached diff.
>>>
>>> Questions arising:
>>>
>>> * is it safe to abandon a sort from inside a comparator?
>>>(can't see anything that suggests otherwise.)
>>>
>>> * are there threading issues that have to be deal with
>>>other than by making the `cancelled` flag volatile?
>>>
>>> If what I suggest appears to be sane I'll make it a
>>>   pull request and run the process.
>>>
>>> Chris
>>>
>>> [1] Using a wrapper to handle the test for cancellation
>>>  and then delegating `compare` to the comparator
>>>  supplied to SortedDataBag.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>

Re: timing out big sorts

[Stian Soiland-Reyes]

First of all the sorting could be sped up significantly on a
multi-core machine by using Java 8's:
http://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#parallelSort-T:A-

(The speed-up can in some cases be much larger than the multiple of
the number of cores)


..sadly the underlying ArraysParallelSortHelpers.FJObject.Sorter is
not publicly accessible, because then its ForkJoinTask could be used
to cancel an ongoing sort.

What about instead using a FutureTask which you cancel with
future.cancel(true), the task would just call Arrays.parallelSort().

The array might be in a weird state if you cancel/interrupt mid-sort
(e.g. duplicate values) - but on cancelling you can clear/forget the
array. And by keeping the array sorting in a separate thread you won't
be interrupting something within Jena's internal (e.g. a TDB index
update)



On 15 July 2016 at 12:08, Chris Dollin  wrote:
> Dear All
>
> When a query with an ORDER BY is cancelled, the component
> Arrays.sort() that sorts the chunk(s) of the result
> bindings runs to completion before the cancel finishes.
> [See QueryIterSort and SortedDataBag.]
>
> For a large result set, this results in a long wait
> before the cancelled request finally finishes. This
> can be inconvenient.
>
> The cancel request can be sneaked into the sort by
> way of the comparator [1] and adding an instance
> variable `cancelled` to SortedDataBag, set `true`
> from QueryIterSort.requestCancel(). The comparator
> checks `cancelled` and if it has become `true`
> throws an exception, which is then caught outside
> the call to Arrays.sort(), abandoning the sort.
> See attached diff.
>
> Questions arising:
>
> * is it safe to abandon a sort from inside a comparator?
>   (can't see anything that suggests otherwise.)
>
> * are there threading issues that have to be deal with
>   other than by making the `cancelled` flag volatile?
>
> If what I suggest appears to be sane I'll make it a
>  pull request and run the process.
>
> Chris
>
> [1] Using a wrapper to handle the test for cancellation
> and then delegating `compare` to the comparator
> supplied to SortedDataBag.
>
>
>
>
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

Re: [DRAFT] Jena board report for July.

[Stian Soiland-Reyes]

looks OK, except "Jena 3.10" should be "Jena 3.1.0" :)

(Or are we planning a Jena for Workgroups next? :)

I don't think we need to include the line:

> The amount of activity is highly dependent on contributor time. There are no 
> directly salaried developers.



On 5 July 2016 at 16:31, Andy Seaborne  wrote:
> ## Description:
>
> Jena is a framework for developing Semantic Web and Linked Data
> applications in Java. It provides implementation of W3C standards for RDF
> and SPARQL.
>
> ## Issues:
> Draft for comments:
>
> -
>
> There are no issues requiring board attention at this time.
>
> ## Activity:
>
> The project has had a routine quarter after the release of Jena 3.10 in May.
>
> The amount of activity is highly dependent on contributor time. There are no
> directly salaried developers.
>
> ## Health report:
>
> The drop in dev@ email can be attributed to the fact the release happened at
> the beginning of the reporting period.  The last cycle was busier because of
> getting the release together and issues coming out of the woodwork followed
> by a quiet period.
>
> ## PMC changes:
>
>  - Currently 12 PMC members.
>  - Adam Soroka was added to the PMC on Mon Jun 06 2016
>
> ## Committer base changes:
>
>  - Currently 14 committers.
>  - Adam Soroka was added as a committer on Mon May 30 2016
>
> ## Releases:
>
>  - 3.1.0 was released on Tue May 10 2016
>
> ## Mailing list activity:
>
>  - us...@jena.apache.org:
> - 632 subscribers (up 9 in the last 3 months):
> - 458 emails sent to list (503 in previous quarter)
>
>  - dev@jena.apache.org:
> - 155 subscribers (up 4 in the last 3 months):
> - 608 emails sent to list (946 in previous quarter)
>
>
> ## JIRA activity:
>
>  - 41 JIRA tickets created in the last 3 months
>  - 39 JIRA tickets closed/resolved in the last 3 months



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

[jira] [Commented] (JENA-1015) Commons RDF module

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1015:
---

Yes, I've linked this issue to COMMONSRDF-33

> Commons RDF module
> --
>
> Key: JENA-1015
> URL: https://issues.apache.org/jira/browse/JENA-1015
> Project: Apache Jena
>  Issue Type: New Feature
>  Components: Jena
>Reporter: A. Soroka
>Priority: Minor
> Attachments: 2016-07-02_commonsrdf-jena.zip
>
>
> Based on a thread on the dev@ mailing list:
> http://markmail.org/search/?q=jena+commons+rdf#query:jena%20commons%20rdf%20list%3Aorg.apache.incubator.jena-dev+page:1+mid:jjljtijtw36f3jf3+state:results
> and mention on the users@ mailing list, there is some desire to implement the 
> Commons RDF API:
> https://commonsrdf.incubator.apache.org/
> This issue is to track just such an effort.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Jena core vs. extensions?

[Stian Soiland-Reyes]

On 4 July 2016 at 17:23, A. Soroka  wrote:


> This seems a bit problematic to me. What about the cases (which are really 
> the cases of interest) for which there is no horizon in time at which the 
> work is to "catch up" in any particular sense, for which the extension 
> modules have an independent future?

That is indeed the danger.. that approach works well for what aims to
be integrated additions. But that said, Fuseki 2 has managed to become
integrated.



> This seems intriguing-- are you suggesting that the new folks would be able 
> to make releases out of the special "sidecar" code-base? What relationship 
> would this proposal have with the formal incubation process? This is kind of 
> asking for Jena to have multiple repositories under the Apache org, which 
> seems reasonable to me, but then, I don't understand the implications for 
> Infra and the work they would have to do for this.

Yes, obviously practically the actual release would have to be done by
an existing committer, but there is nothing stopping a PMC to own
multiple git repositories, see for instance: http://git.apache.org/

It's just a few clicks in Jira to ask Infra to make a new repository -
with a few checks later that say the GitHub Pull Request integrations
are working.



> I think this makes sense for a lot of possible projects (larger ones, 
> mostly). But the example in hand (a Commons RDF impl) is one where the size 
> of project doesn't seem to merit a new Apache incubation, right?

No, that's the kind of thing a PMC can just bootstrap on its own.

BTW - I've now added
https://github.com/apache/incubator-commonsrdf/tree/jena/jena so I
guess that particular example is now moot :)


> I like this, in many ways. It's low-cost, simple, and flexible. But I don't 
> know enough about Apache methods to understand what the implications are for 
> "ownership". Is it possible for a project (Jena) to "lay claim" to a GitHub 
> org like that without some kind of formal arrangement with GitHub, and if 
> not, is that formalization difficult or costly?

Such a GitHub group would not be formally associated with ASF or Jena
PMC (and that would have to be made clear) - just with particular
individuals who happen to also be part of Jena.

See the bottom of
https://taverna.incubator.apache.org/download/code/#taverna-extras
for how we did this - note that we used it more of a 'dumping ground'
for license incompatible stuff - that kind of thing would earlier have
been done at "Apache Extras" at Google Code
https://code.google.com/a/apache-extras.org/hosting/ - but as Google
Code now is in Read-only that is no longer an option.



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

Re: Commons RDF (was: Jena core vs. extensions?)

[Stian Soiland-Reyes]

Thank you! I'll adapt it into a new branch and update if needed.

On 2 Jul 2016 12:27 p.m., "Andy Seaborne"  wrote:

> On 02/07/16 01:23, Stian Soiland-Reyes wrote:
>
>> I think Andy's approach is great, I have extended it with parser
>> support inhttps://github.com/stain/commonsrdf-parser-jena  - but I've
>> not submitted this to Commons RDF yet;  as Andy's code was not
>> formally contributed to ASF I didn't want to do this on his behalf.  I
>> had considered to do a "clean room" approach - but of course my mind
>> would be tainted :)  Feel free to use my code though!
>>
> >
>
>> So a similar jena module/branch would very much be welcome at Commons
>> RDF - I would be very pleased if you would consider to contribute to
>> it! :)
>>
>
> The code is licensed with the Apache License.
>
> https://github.com/afs/commonsrdf-jena/blob/master/LICENSE
>
> The Apache License grants you the right to use and modify the code.
> Contribution is not a precondition!
>
> If you would prefer me to contribute: I've zipped it up and attached it to
> JENA-1015.
>
>
> https://issues.apache.org/jira/secure/attachment/12815904/2016-07-02_commonsrdf-jena.zip
>
> Andy
>
>

Re: Jena core vs. extensions?

[Stian Soiland-Reyes]

incompatible licenses, e.g.
4store (GPL).  Community-wise there's a danger that this would form a
"lower tier" and risk making it harder to become part of the Jena PMC,
as any new and cool stuff could just be sent straight to jena-extras,
where the newcomers don't get to learn the "Apache Way" and perhaps
don't even communicate with each others moduels.


Discuss! ;-)

-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

Re: Jena core vs. extensions?

[Stian Soiland-Reyes]

On 1 July 2016 at 15:46, A. Soroka  wrote:

> On the other hand, a real sharp and simple (and inexpensive) approach would 
> be to say that Jena just doesn't maintain any non-core modules. If a non-core 
> module is interesting enough to a community that intersects with that of 
> Jena, it's on that community to find a home for it, either independently or 
> via some other project (Apache or no). For example, I'd be curious as to 
> whether the Commons RDF project could help host a Jena impl of Commons RDF. 
> This scheme has the advantage of minimal burden on Jena.

Hi!

Glad you are picking up interest in Commons RDF and Jena :)

For Commons RDF now we have dropped the earlier goal of being a
"upper" interface for all the RDF frameworks.  It could still very
well work like that, but the problem that held us back I think was the
stability issue - e.g. framework X didn't want to integrate with
Commons RDF before it was "stable" (as in 1.0 and graduated from
incubator?) - while Commons RDF didn't move forward without having any
integrations to test it with.

So now we have reconsidered our goals, and as our target is to
graduate to be a component of Apache Commons, then we are now looking
at the option of hosting integration modules ourselves as part of
Commons RDF, similar to how Commons VFS has a set of implementations.

Naturally these would then be wrappers rather than tighter integration
as if you could modify the native classes of the framework - but if
you do it carefully you can see it can be done without too much
"translation" or cloning overhead.


For instance the rdf4j module I would say is near complete now:

https://github.com/apache/incubator-commonsrdf/tree/rdf4j/rdf4j


(Note that this is based on the parser-with-quads branch which
includes new Dataset/Quad interfaces and the RDFParserBuilder
interface. Feedback very much welcome on both of these!  See
https://github.com/apache/incubator-commonsrdf/pulls )




I think Andy's approach is great, I have extended it with parser
support in https://github.com/stain/commonsrdf-parser-jena - but I've
not submitted this to Commons RDF yet;  as Andy's code was not
formally contributed to ASF I didn't want to do this on his behalf.  I
had considered to do a "clean room" approach - but of course my mind
would be tainted :)  Feel free to use my code though!


So a similar jena module/branch would very much be welcome at Commons
RDF - I would be very pleased if you would consider to contribute to
it! :)   Perhaps there's baked in a lot of "know-how" in the rdf4j
approach that we should document - but it would be good to know your
take as well, and questions that come up.


There should not be a problem with the Apache Commons RDF hosting the
integrations, as (on graduating to Commons) any ASF committers can
update/fix them, and also a submitted pull request to update some
pom.xml etc. would be easily reviewed by any of the Commons
committers.

If we change our mind, then it's very easy to move the integration
over to jena-core with ASF - if rdf4j wanted to do the same I am
willing to contribute my commits on that separately to the Eclipse
foundation.


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

Re: out-of-space problems with build

[Stian Soiland-Reyes]

On 6 June 2016 at 10:03, Rob Vesse  wrote:
> I’ve always seen this issue running on mac , these days it is not an issue 
> for me because I got a new machine with more disk space
>
> It did always seem like there was a delay between the test deleting folder 
> and the disk space actually being freed up. I did on one occasion try 
> inserting a sleep before each test which made things better but drastically 
> increased the time to run the tests.

Could this be related to encryption of home directory? In my
experience that could add a noticeable delay before disk space is
freed up.

Is it possible to safely re-use a previously malloc-ed test-file, or
would that introduce lots of other issues? (It sounds non-ideal, each
tests should run independently from a clean state).   What about
truncating the file before it's deleted?



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

Re: mailing list archives

[Stian Soiland-Reyes]

+1 to use the lovely
https://lists.apache.org/list.html?dev@jena.apache.org and friends for
everything - including in say [RESULT] emails (try the Permalink
button)

The only thing is that I can't seem to find subscribe/unsubscribe info
there - but we describe that manually already on
http://jena.apache.org/help_and_support/

On 31 May 2016 at 15:41, A. Soroka  wrote:
> I've really been enjoying the new lists.apache.org system, and as far as I 
> understand, it's in full production now. Our Maven metadata and website 
> currently aim people variously at:
>
> http://mail-archives.apache.org/
> http://jena.markmail.org/search/
> http://markmail.org/search/?q=list%3Aorg.apache.jena.[users|dev]
> https://www.mail-archive.com/[users|dev]@jena.apache.org/
>
> Is everyone okay if I go ahead and add links for lists.apache.org? Any 
> opinions about whether we should pick one archive and point people at it?
>
> ---
> A. Soroka
> The University of Virginia Library
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

Re: [] Release Jena 3.1.0 (3rd proposed candidate)

[Stian Soiland-Reyes]

+1 to make the source build+tests pass by default on most machines
without say excessive time or disk requirement (including Windows).

We should however force all tests in the -Papache-release profile -
meaning you have to do the release process with Linux/OSX or (in
theory) on a Windows with a working Hadoop.

On 12 May 2016 at 17:12, Andy Seaborne  wrote:
> The JDBC TDB tests are quite exhaustive but from TDB's point-of-view,
> getting through the jena-tdb tests is enough IMO (if not we need to put a
> test into jena-tdb).  The jena-jdbc-tdb uses TDB a lot in a few predictable
> ways.  I've not looked but it might be possible to use TDB-in-memory for
> them.  Like the hadoop tests - the framework is at fault, not the code being
> tested.
>
>
> I've started a BUILD file to go in the root of the source tree to document
> these findings.
>
>
> On balance, I think a setup whereby the default "mvn clean install" on
> windows does something reasonably safe and reasonably useful is better than
> something that breaks easily.  Maybe that should be bootstrap (shade guava)
> then through to Fuseki2, + build binaries.
>
> Skipping some tests while still building, in the default setup, is a
> possible alternative.  Considering the likely user (e.g. someone picking up
> a bug fix or working on a git-clone) making the basics work well, i.e.
> build-test, seems to me to be a better choice
>
> Andy
>
>
>
> On 12/05/16 14:56, Osma Suominen wrote:
>>
>> FWIW, I tried building on a Windows 10 VM (this is the 64bit IE11/Win10
>> test image from http://modern.ie that I normally use for browser testing).
>>
>> I couldn't complete the build though. The JDBC TDB Driver tests seemed
>> to consume an enormous amount of disk space. Even though I increased the
>> amount of disk space available to the VM (twice - up to 80GB, of which
>> the jena-3.1.0 folder eventually consumed about 64GB), I ran out of
>> space in the end. I gave up before reaching the Elephas build.
>>
>> I'm probably again doing something stupid though. Someone more familiar
>> with doing Java development on Windows should try this.
>>
>> -Osma
>>
>> On 12/05/16 14:03, Stian Soiland-Reyes wrote:
>>>
>>> Sorry, Windows 10 is not happy in building Elephas - something goes
>>> wrong with the hadoop file system (sounds like a Hadoop bug rather
>>> than Jena)
>>>
>>> mvn clean install fails at:
>>>
>>> [INFO] Apache Jena - Elephas - I/O  FAILURE
>>> [09:44 min]
>>> [INFO] Apache Jena - Elephas - Map/Reduce . SKIPPED
>>> [INFO] Apache Jena - Elephas - Statistics Demo App  SKIPPED
>>> [INFO] Apache Jena - Distribution . SKIPPED
>>> [INFO] Apache Jena - OSGi . SKIPPED
>>> [INFO] Apache Jena - OSGi bundle .. SKIPPED
>>> [INFO] Apache Jena - OSGi Karaf features .. SKIPPED
>>> [INFO] Apache Jena - Extras ... SKIPPED
>>> [INFO] Apache Jena - Extras - Query Builder ... SKIPPED
>>> [INFO] Apache Jena  SKIPPED
>>>
>>> (In other words, all the other worked fine :)
>>>
>>>
>>> output_04[3](org.apache.jena.hadoop.rdf.io.output.turtle.StreamedTurtleOutputTest)
>>>
>>>   Time elapsed: 0.017 sec  <<< ERROR!
>>> java.lang.NullPointerException: null
>>>  at java.lang.ProcessBuilder.start(ProcessBuilder.java:1012)
>>>  at org.apache.hadoop.util.Shell.runCommand(Shell.java:482)
>>>  at org.apache.hadoop.util.Shell.run(Shell.java:455)
>>>  at
>>> org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:715)
>>>  at org.apache.hadoop.util.Shell.execCommand(Shell.java:808)
>>>  at org.apache.hadoop.util.Shell.execCommand(Shell.java:791)
>>>  at
>>>
>>> org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:656)
>>>
>>>  at
>>>
>>> org.apache.hadoop.fs.FilterFileSystem.setPermission(FilterFileSystem.java:490)
>>>
>>>  at
>>>
>>> org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:462)
>>>
>>>  at
>>>
>>> org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:428)
>>>
>>>  at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:908)
>>> 

Re: [] Release Jena 3.1.0 (3rd proposed candidate)

[Stian Soiland-Reyes]

Thanks for having a go!

No, this is a general problem with testing TDB in windows due to memory
mapped files and file locking. I think I had 120 GB free, so I guess I was
quite lucky!

We discussed changing to forked mode to reduce the problem, but then still
the tests must be broken down to more *Test classes as forked junit tests
still run one class at a time.

So I think we can say to build on Windows, use -DskipTests.

On 12 May 2016 2:56 p.m., "Osma Suominen"  wrote:

> FWIW, I tried building on a Windows 10 VM (this is the 64bit IE11/Win10
> test image from http://modern.ie that I normally use for browser testing).
>
> I couldn't complete the build though. The JDBC TDB Driver tests seemed to
> consume an enormous amount of disk space. Even though I increased the
> amount of disk space available to the VM (twice - up to 80GB, of which the
> jena-3.1.0 folder eventually consumed about 64GB), I ran out of space in
> the end. I gave up before reaching the Elephas build.
>
> I'm probably again doing something stupid though. Someone more familiar
> with doing Java development on Windows should try this.
>
> -Osma
>
> On 12/05/16 14:03, Stian Soiland-Reyes wrote:
>
>> Sorry, Windows 10 is not happy in building Elephas - something goes
>> wrong with the hadoop file system (sounds like a Hadoop bug rather
>> than Jena)
>>
>> mvn clean install fails at:
>>
>> [INFO] Apache Jena - Elephas - I/O  FAILURE
>> [09:44 min]
>> [INFO] Apache Jena - Elephas - Map/Reduce . SKIPPED
>> [INFO] Apache Jena - Elephas - Statistics Demo App  SKIPPED
>> [INFO] Apache Jena - Distribution . SKIPPED
>> [INFO] Apache Jena - OSGi . SKIPPED
>> [INFO] Apache Jena - OSGi bundle .. SKIPPED
>> [INFO] Apache Jena - OSGi Karaf features .. SKIPPED
>> [INFO] Apache Jena - Extras ... SKIPPED
>> [INFO] Apache Jena - Extras - Query Builder ... SKIPPED
>> [INFO] Apache Jena  SKIPPED
>>
>> (In other words, all the other worked fine :)
>>
>>
>> output_04[3](org.apache.jena.hadoop.rdf.io.output.turtle.StreamedTurtleOutputTest)
>>   Time elapsed: 0.017 sec  <<< ERROR!
>> java.lang.NullPointerException: null
>>  at java.lang.ProcessBuilder.start(ProcessBuilder.java:1012)
>>  at org.apache.hadoop.util.Shell.runCommand(Shell.java:482)
>>  at org.apache.hadoop.util.Shell.run(Shell.java:455)
>>  at
>> org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:715)
>>  at org.apache.hadoop.util.Shell.execCommand(Shell.java:808)
>>  at org.apache.hadoop.util.Shell.execCommand(Shell.java:791)
>>  at
>> org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:656)
>>  at
>> org.apache.hadoop.fs.FilterFileSystem.setPermission(FilterFileSystem.java:490)
>>  at
>> org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:462)
>>  at
>> org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:428)
>>  at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:908)
>>  at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:889)
>>  at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:786)
>>  at org.apache.jena.hadoop.rdf.io
>> .output.AbstractNodeTupleOutputFormat.getRecordWriter(AbstractNodeTupleOutputFormat.java:77)
>>  at org.apache.jena.hadoop.rdf.io
>> .output.AbstractNodeTupleOutputFormatTests.testOutput(AbstractNodeTupleOutputFormatTests.java:199)
>>  at org.apache.jena.hadoop.rdf.io
>> .output.AbstractNodeTupleOutputFormatTests.output_04(AbstractNodeTupleOutputFormatTests.java:253)
>>  at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
>>  at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:498)
>>  at
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>  at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>  at
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>>  at
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>>  at
>> org.junit.rules.ExternalResource$1.evaluate(ExternalRe

Re: [jira] [Commented] (JENA-1178) JSON-LD https @contexts does not work

[Stian Soiland-Reyes]

(Somehow I'm not allowed to Comment on my own Jira issue, so I'll reply here)


On 11 May 2016 at 18:06, Andy Seaborne (JIRA)  wrote:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201605.mbox/%3C573313F7.4050408%40apache.org%3E
> It works when jena-parent is updated for HTTPClient and java-jsonld.
> However, a lot of warnings appear and HTTPcient is central to remote SPARQL.

OK, then that is a good workaround for anyone (like me) needing this -
upgrade jsonld-java and httpclient "at your own risk".

> I am against rushing to update for a release.


I agree this should not hold back 3.1.0 release; as it's not a
regression from 3.0.x.

Shall we plan it for 3.1.1? (I've ambituously set that as Fix For
version). Then we can work through the warnings after changing it on
master, post 3.1.0.



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

[jira] [Updated] (JENA-1178) JSON-LD https @contexts does not work

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes updated JENA-1178:
--
Fix Version/s: Jena 3.1.1

> JSON-LD https @contexts does not work
> -
>
> Key: JENA-1178
> URL: https://issues.apache.org/jira/browse/JENA-1178
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, RIOT
>Affects Versions: Jena 3.0.0, Jena 3.0.1, Jena 3.1.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
> Maven home: /home/stain/software/maven
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-22-generic", arch: "amd64", family: "unix"
>Reporter: Stian Soiland-Reyes
>  Labels: https, json-ld, jsonld
> Fix For: Jena 3.1.1
>
>
> I am unable to use https JSON-LD @contexts - something with https is not 
> working. Basically this breaks anything at https://w3id.org/ which is popular 
> in JSON-LD community.
> This was broken in 3.0.0, 3.0.1 and 3.1.0 RC3.  
> Upgrading JSON-LD Java to 0.8.2 and corresponding 
> httpclient/httpclient-cache/httpcore seems to fix the issue.
> {code}
> stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
> {"@context": "https://w3id.org/bundle/context.json";, "aggregates":
> "http://example.com/soup"; }
> 17:04:59 ERROR riot :: invalid remote context:
> https://w3id.org/bundle/context.json
> {code}
> Trying to follow the redirection does not help, as it goes to https as well:
> {code}
> stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
> {"@context": 
> "https://rawgit.com/researchobject/specifications/gh-pages/bundle/context.json";,
> "aggregates": "http://example.com/soup"; }
> 17:05:59 ERROR riot :: invalid remote context:
> https://rawgit.com/researchobject/specifications/gh-pages/bundle/context.json
> {code}
> Using http instead of https works - so the context is not at fault:
> {code}
> stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
> {"@context": 
> "http://rawgit.com/researchobject/specifications/gh-pages/bundle/context.json";,
> "aggregates": "http://example.com/soup"; }
> _:B9c444c8e486c7be3e4a49bbaaff22bc8
> <http://www.openarchives.org/ore/terms/aggregates>
> <http://example.com/soup> .
> {code}
> So I tried with another w3id-identified context, which also fails:
> {code}
> stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
> {"@context": "https://w3id.org/payswarm/v1";, "paymentMethod": "Visa" }
> 17:07:45 ERROR riot :: invalid remote context:
> https://w3id.org/payswarm/v1
> {code}
> I get the same errors with 3.0.0 and 3.0.1, so perhaps this is not a
> blocker for this RC.
> Dropping in lib/httpclient-4.5.1.jar  lib/httpclient-cache-4.5.1.jar
> lib/httpcore-4.4.4.jar  lib/jsonld-java-0.8.2.jar
> fixes this issue for both cases:
> {code}
> stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
> {"@context": "https://w3id.org/payswarm/v1";, "paymentMethod": "Visa" }
> _:Bbd3ab47b6dc78802bd11266c6dff7b5c
> <https://w3id.org/commerce#paymentMethod>
> <https://w3id.org/commerce/creditcard#Visa> .
> {code}
> {code}
> stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
> {"@context": "https://w3id.org/bundle/context.json";, "aggregates":
> "http://example.com/soup"; }
> _:B4c8067a2a952151f5b2251f8a35c53dc
> <http://www.openarchives.org/ore/terms/aggregates>
> <http://example.com/soup> .
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [] Release Jena 3.1.0 (3rd proposed candidate)

[Stian Soiland-Reyes]

OK, so I guess if those Hadoop binaries are needed, then the best is
for Elephas build to not run the tests if on Windows, then?  (It
should still be OK to COMPILE it - although of course it wouldn't be
something you would be able to use)



On 12 May 2016 at 13:16, Andy Seaborne  wrote:
> https://wiki.apache.org/hadoop/Hadoop2OnWindows
>
> says
>
> """
> The official Apache Hadoop releases do not include Windows binaries (yet, as
> of January 2014).
> """
>
> The test dependency is on hadoop-mini-cluster 2.6.0 which was Nov 2014.
>
> (mrunit 1.0.0 is April 2.3.0)
>
> It may just not run for testing on Windows.
>
>
> Andy
>
>
> The Jenkins windows job is disabled because it takes so much tmp space and
> that was causing problems for stability of the build server.  If the JVM
> crashed, then tmp files didn't get cleaned; if tmp was a bit full, the peak
> size was a problem.
>
> It runs -Pdev (and still does run - I just checked - I left it disabled
> though).
>
>
>
>
> On 12/05/16 12:06, Bruno P. Kinoshita wrote:
>>
>> I am quite sure I have a Windows VM somewhere at work. I can give it a try
>> tomorrow Stian. I'm compiling on Linux right now.
>> Cheers
>>
>>
>>From: Stian Soiland-Reyes 
>>   To: dev@jena.apache.org
>>   Sent: Thursday, 12 May 2016 11:03 PM
>>   Subject: Re: [] Release Jena 3.1.0 (3rd proposed candidate)
>>
>> Sorry, Windows 10 is not happy in building Elephas - something goes
>> wrong with the hadoop file system (sounds like a Hadoop bug rather
>> than Jena)
>>
>> mvn clean install fails at:
>>
>> [INFO] Apache Jena - Elephas - I/O  FAILURE [09:44
>> min]
>> [INFO] Apache Jena - Elephas - Map/Reduce . SKIPPED
>> [INFO] Apache Jena - Elephas - Statistics Demo App  SKIPPED
>> [INFO] Apache Jena - Distribution . SKIPPED
>> [INFO] Apache Jena - OSGi . SKIPPED
>> [INFO] Apache Jena - OSGi bundle .. SKIPPED
>> [INFO] Apache Jena - OSGi Karaf features .. SKIPPED
>> [INFO] Apache Jena - Extras ... SKIPPED
>> [INFO] Apache Jena - Extras - Query Builder ... SKIPPED
>> [INFO] Apache Jena  SKIPPED
>>
>> (In other words, all the other worked fine :)
>>
>>
>> output_04[3](org.apache.jena.hadoop.rdf.io.output.turtle.StreamedTurtleOutputTest)
>>   Time elapsed: 0.017 sec  <<< ERROR!
>> java.lang.NullPointerException: null
>>  at java.lang.ProcessBuilder.start(ProcessBuilder.java:1012)
>>  at org.apache.hadoop.util.Shell.runCommand(Shell.java:482)
>>  at org.apache.hadoop.util.Shell.run(Shell.java:455)
>>  at
>> org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:715)
>>  at org.apache.hadoop.util.Shell.execCommand(Shell.java:808)
>>  at org.apache.hadoop.util.Shell.execCommand(Shell.java:791)
>>  at
>> org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:656)
>>  at
>> org.apache.hadoop.fs.FilterFileSystem.setPermission(FilterFileSystem.java:490)
>>  at
>> org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:462)
>>  at
>> org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:428)
>>  at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:908)
>>  at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:889)
>>  at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:786)
>>  at
>> org.apache.jena.hadoop.rdf.io.output.AbstractNodeTupleOutputFormat.getRecordWriter(AbstractNodeTupleOutputFormat.java:77)
>>  at
>> org.apache.jena.hadoop.rdf.io.output.AbstractNodeTupleOutputFormatTests.testOutput(AbstractNodeTupleOutputFormatTests.java:199)
>>  at
>> org.apache.jena.hadoop.rdf.io.output.AbstractNodeTupleOutputFormatTests.output_04(AbstractNodeTupleOutputFormatTests.java:253)
>>  at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
>>  at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:498)
>>  at
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>  at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12

Re: [] Release Jena 3.1.0 (3rd proposed candidate)

[Stian Soiland-Reyes]

Sorry, Windows 10 is not happy in building Elephas - something goes
wrong with the hadoop file system (sounds like a Hadoop bug rather
than Jena)

mvn clean install fails at:

[INFO] Apache Jena - Elephas - I/O  FAILURE [09:44 min]
[INFO] Apache Jena - Elephas - Map/Reduce . SKIPPED
[INFO] Apache Jena - Elephas - Statistics Demo App  SKIPPED
[INFO] Apache Jena - Distribution . SKIPPED
[INFO] Apache Jena - OSGi . SKIPPED
[INFO] Apache Jena - OSGi bundle .. SKIPPED
[INFO] Apache Jena - OSGi Karaf features .. SKIPPED
[INFO] Apache Jena - Extras ... SKIPPED
[INFO] Apache Jena - Extras - Query Builder ... SKIPPED
[INFO] Apache Jena  SKIPPED

(In other words, all the other worked fine :)

output_04[3](org.apache.jena.hadoop.rdf.io.output.turtle.StreamedTurtleOutputTest)
 Time elapsed: 0.017 sec  <<< ERROR!
java.lang.NullPointerException: null
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1012)
at org.apache.hadoop.util.Shell.runCommand(Shell.java:482)
at org.apache.hadoop.util.Shell.run(Shell.java:455)
at 
org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:715)
at org.apache.hadoop.util.Shell.execCommand(Shell.java:808)
at org.apache.hadoop.util.Shell.execCommand(Shell.java:791)
at 
org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:656)
at 
org.apache.hadoop.fs.FilterFileSystem.setPermission(FilterFileSystem.java:490)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:462)
at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:428)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:908)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:889)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:786)
at 
org.apache.jena.hadoop.rdf.io.output.AbstractNodeTupleOutputFormat.getRecordWriter(AbstractNodeTupleOutputFormat.java:77)
at 
org.apache.jena.hadoop.rdf.io.output.AbstractNodeTupleOutputFormatTests.testOutput(AbstractNodeTupleOutputFormatTests.java:199)
at 
org.apache.jena.hadoop.rdf.io.output.AbstractNodeTupleOutputFormatTests.output_04(AbstractNodeTupleOutputFormatTests.java:253)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
 

Re: [] Release Jena 3.1.0 (3rd proposed candidate)

[Stian Soiland-Reyes]

On 11 May 2016 at 17:49, Andy Seaborne  wrote:
>> Vote: 0 as the JSON-LD downgrade breaks JSON-LD https contexts.
> Release votes are majority (binding), min +3.
> (I'm not clear on what your vote is - the first line or the whole message.)

My overall vote was 0 - as indicated on the top. The rest was a
breakdown. Sorry for not making that clearer.


Of course nobody can block a release anyway (except perhaps on legal
reasons) if there's enough +1 - I meant I don't think you should
consider my "discovery" as a blocker  :)


mvn install works on Ubuntu 16.04, btw.

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-22-generic", arch: "amd64", family: "unix"


I'll have a go in Windows 10 x64 as well.


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: [VOTE] Release Jena 3.1.0 (3rd proposed candidate)

[Stian Soiland-Reyes]

uery/construct-quad.html
>
> * DatasetGraphs & transactions integration
>
> * Alternative QueryParsers in jena-text
>
> * new module jena-cmds
> "jena.*"
>
> * Fuseki: Multiple service per file, shared datasets
>
> * Logging
> log4j marked 
>
> * New custom functions and aggregate functions
> Added:
> * afn:sprintf (contribution from Alessandro Seganti)
> * The XQuery/XPath Functions and Operators "math:" functions
> * Custom aggregates for stdev etc. (also STDEV etc as keywords).
>
> * FactoryRDF
> Parsing RDF now saves space by interning RDFTerms created
> during a each parser run.
>
> * OSGi fixes (Jaroslav Pullmann)
>
> * General maintenance: about 80 JIRA.
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: [VOTE] Release Jena 3.1.0 (3rd proposed candidate)

[Stian Soiland-Reyes]

On 11 May 2016 at 17:18, Stian Soiland-Reyes  wrote:
> Vote: 0 as the JSON-LD downgrade breaks JSON-LD https contexts.

Tracked as https://issues.apache.org/jira/browse/JENA-1178



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

[jira] [Created] (JENA-1178) JSON-LD https @contexts does not work

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created JENA-1178:
-

 Summary: JSON-LD https @contexts does not work
 Key: JENA-1178
 URL: https://issues.apache.org/jira/browse/JENA-1178
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ, RIOT
Affects Versions: Jena 3.0.1, Jena 3.0.0, Jena 3.1.0
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-22-generic", arch: "amd64", family: "unix"
    Reporter: Stian Soiland-Reyes


I am unable to use https JSON-LD @contexts - something with https is not 
working. Basically this breaks anything at https://w3id.org/ which is popular 
in JSON-LD community.

This was broken in 3.0.0, 3.0.1 and 3.1.0 RC3.  

Upgrading JSON-LD Java to 0.8.2 and corresponding 
httpclient/httpclient-cache/httpcore seems to fix the issue.


{code}
stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
{"@context": "https://w3id.org/bundle/context.json";, "aggregates":
"http://example.com/soup"; }
17:04:59 ERROR riot :: invalid remote context:
https://w3id.org/bundle/context.json
{code}

Trying to follow the redirection does not help, as it goes to https as well:

{code}
stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
{"@context": 
"https://rawgit.com/researchobject/specifications/gh-pages/bundle/context.json";,
"aggregates": "http://example.com/soup"; }
17:05:59 ERROR riot :: invalid remote context:
https://rawgit.com/researchobject/specifications/gh-pages/bundle/context.json
{code}

Using http instead of https works - so the context is not at fault:

{code}
stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
{"@context": 
"http://rawgit.com/researchobject/specifications/gh-pages/bundle/context.json";,
"aggregates": "http://example.com/soup"; }
_:B9c444c8e486c7be3e4a49bbaaff22bc8
<http://www.openarchives.org/ore/terms/aggregates>
<http://example.com/soup> .
{code}

So I tried with another w3id-identified context, which also fails:

{code}
stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
{"@context": "https://w3id.org/payswarm/v1";, "paymentMethod": "Visa" }
17:07:45 ERROR riot :: invalid remote context:
https://w3id.org/payswarm/v1
{code}

I get the same errors with 3.0.0 and 3.0.1, so perhaps this is not a
blocker for this RC.


Dropping in lib/httpclient-4.5.1.jar  lib/httpclient-cache-4.5.1.jar
lib/httpcore-4.4.4.jar  lib/jsonld-java-0.8.2.jar

fixes this issue for both cases:

{code}
stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
{"@context": "https://w3id.org/payswarm/v1";, "paymentMethod": "Visa" }
_:Bbd3ab47b6dc78802bd11266c6dff7b5c
<https://w3id.org/commerce#paymentMethod>
<https://w3id.org/commerce/creditcard#Visa> .
{code}

{code}
stain@biggie:~/Downloads/95/apache-jena-3.1.0$ bin/riot --syntax jsonld
{"@context": "https://w3id.org/bundle/context.json";, "aggregates":
"http://example.com/soup"; }
_:B4c8067a2a952151f5b2251f8a35c53dc
<http://www.openarchives.org/ore/terms/aggregates>
<http://example.com/soup> .
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Jena 3.1.0 (3rd proposed candidate)

[Stian Soiland-Reyes]

expected time and we can
> extend the vote period.
>
> Thanks,
>
> Andy
>
> Checking:
>
> + does everything work on Linux?
> + does everything work on MS Windows?
> + does everything work on OS X?
> + are the GPG signatures fine?
> + are the checksums correct?
> + is there a source archive?
> + can the source archive really be built?
> + is there a correct LICENSE and NOTICE file in each artifact
>   (both source and binary artifacts)?
> + does the NOTICE file contain all necessary attributions?
> + have any licenses of dependencies changed due to upgrades?
>if so have LICENSE and NOTICE been upgraded appropriately?
> + does the tag/commit in the SCM contain reproducible sources?
>
>
> ---
>
> Key features of the release:
>
> * In-memory txn dataset (Adam Soroka) (RC in 3.0.1)
>
> http://jena.staging.apache.org/documentation/rdf/datasets.html
>
> * Quads (Qihong Lin) (RC in 3.0.1)
>
> http://jena.staging.apache.org/documentation/query/construct-quad.html
>
> * DatasetGraphs & transactions integration
>
> * Alternative QueryParsers in jena-text
>
> * new module jena-cmds
> "jena.*"
>
> * Fuseki: Multiple service per file, shared datasets
>
> * Logging
> log4j marked 
>
> * New custom functions and aggregate functions
> Added:
> * afn:sprintf (contribution from Alessandro Seganti)
> * The XQuery/XPath Functions and Operators "math:" functions
> * Custom aggregates for stdev etc. (also STDEV etc as keywords).
>
> * FactoryRDF
> Parsing RDF now saves space by interning RDFTerms created
> during a each parser run.
>
> * OSGi fixes (Jaroslav Pullmann)
>
> * General maintenance: about 80 JIRA.
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

[jira] [Commented] (JENA-1176) JSON-LD @context parsing fails due to outdated HTTPClient

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1176:
---

Agreed that needs to be tested more.

Also we need to add tests for JSON-LD parsing with 'external' @context. (the 
very same JAR cache could be used to avoid it actually being external)

I'll have a go to see if the setDefaultClient workaround can sneak in for 3.1.0 
- otherwise I would downgrade to JSONLD-Java 0.7.x

> JSON-LD @context parsing fails due to outdated HTTPClient
> -
>
> Key: JENA-1176
> URL: https://issues.apache.org/jira/browse/JENA-1176
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Stian Soiland-Reyes
>Priority: Blocker
>  Labels: httpclient, jsonld
> Fix For: Jena 3.1.0
>
>
> Raised by 
> [Francois|http://mail-archives.apache.org/mod_mbox/jena-dev/201605.mbox/%3CB51A2FF9-23E8-460B-913D-43BAB7A07E29%40gmail.com%3E]:
> {code}
> public class TestJsonLDReader {
>   @Test public final void test() {
>   String jsonld = 
> "{\"@id\":\"_:b0\",\"@type\":\"http://schema.org/Person\",\"name\":\"John
> Doe\",\"@context\":\"http://schema.org/\"}";;
>   StringReader reader = new StringReader(jsonld);
>   Model m = ModelFactory.createDefaultModel();
>   m.read(reader, null, "JSON-LD");
>   m.write(System.out, "TURTLE");
>   }
> }
> {code}
> Fails with:
> {code}
> java.lang.NoSuchMethodError: 
> org.apache.http.impl.client.cache.CacheConfig.custom()Lorg/apache/http/impl/client/cache/CacheConfig$Builder;
>   at 
> com.github.jsonldjava.utils.JsonUtils.createDefaultHttpClient(JsonUtils.java:333)
>   at 
> com.github.jsonldjava.utils.JsonUtils.getDefaultHttpClient(JsonUtils.java:323)
>   at 
> com.github.jsonldjava.core.DocumentLoader.getHttpClient(DocumentLoader.java:84)
>   at 
> com.github.jsonldjava.core.DocumentLoader.fromURL(DocumentLoader.java:59)
>   at 
> com.github.jsonldjava.core.DocumentLoader.loadDocument(DocumentLoader.java:29)
>   at com.github.jsonldjava.core.Context.parse(Context.java:169)
>   at com.github.jsonldjava.core.Context.parse(Context.java:252)
>   at com.github.jsonldjava.core.JsonLdApi.expand(JsonLdApi.java:534)
>   at com.github.jsonldjava.core.JsonLdApi.expand(JsonLdApi.java:981)
>   at 
> com.github.jsonldjava.core.JsonLdProcessor.expand(JsonLdProcessor.java:146)
>   at 
> com.github.jsonldjava.core.JsonLdProcessor.toRDF(JsonLdProcessor.java:482)
>   at org.apache.jena.riot.lang.JsonLDReader.read$(JsonLDReader.java:143)
>   at org.apache.jena.riot.lang.JsonLDReader.read(JsonLDReader.java:64)
> {code}
> This is caused by a newer [JSONLD-Java 
> 0.8.2|https://github.com/jsonld-java/jsonld-java/blob/v0.8.2/pom.xml#L42] now 
> depending on 
> {code:xml}
>   4.5.1
>   4.4.4
> {code} 
> while we explicitly depend on a much older version:
> {code:xml}
> 
> 4.2.6
> 4.2.5
> {code}
> Issue JENA-576 discusses why HTTPClient was not upgraded.
> I suggest we try again to upgrade HTTPClient, even if this means also a newer 
> Solr. 
> A workaround would be to have an initialization to set 
> JsonUtils.setDefaultClient() with our own instance - however that would break 
> JSON-LD [Context JAR 
> caching|https://github.com/jsonld-java/jsonld-java#loading-contexts-from-classpathjar]
>  which I know we use in Taverna to avoid network traffic.
> As JSON-LD with external @context - e.g. with schema.org,  is the primary way 
> to use JSON-LD, then I think this should be a blocker for 3.1.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Created] (JENA-1176) JSON-LD @context parsing fails due to outdated HTTPClient

[Stian Soiland-Reyes]

Because JSON-LD is the most popular RDF format for current usages of
Linked Data (e.g. is heavily used by W3C LDP and W3C Web Annotation)
and I don't think we should regress on its support.

Perhaps the smaller workaround with setting the httpClient in JSON-LDs
JsonUtils will do? We can set it to our own 4.2.6 caching httpclient.
I can have a quick go - even if this means loosing my beloved jar
cache for 3.1.0 ..





On 9 May 2016 at 14:07, Andy Seaborne  wrote:
> On 09/05/16 13:54, Stian Soiland-Reyes (JIRA) wrote:
>>
>>  Priority: Blocker
>>   Fix For: Jena 3.1.0
>
>
> As per the other email thread - the offer is a 3.1.1 very soon.  Why is that
> not acceptable?
>
> Andy
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

[jira] [Commented] (JENA-1176) JSON-LD @context parsing fails due to outdated HTTPClient

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1176:
---

affects riot as well with the 3.1.0 RC2:

{code}
stain@biggie:~/Downloads/apache-jena-3.1.0$ bin/riot --syntax=jsonld
{"@context": "https://w3id.org/bundle/context";,
 "id": "http://example.com/fred";,
 "aggregates": "http://example.com/other";
}
^D
{code}

fails with

{code}
Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.http.impl.client.cache.CacheConfig.custom()Lorg/apache/http/impl/client/cache/CacheConfig$Builder;
at 
com.github.jsonldjava.utils.JsonUtils.createDefaultHttpClient(JsonUtils.java:333)
..
{code}

> JSON-LD @context parsing fails due to outdated HTTPClient
> -
>
> Key: JENA-1176
> URL: https://issues.apache.org/jira/browse/JENA-1176
>     Project: Apache Jena
>  Issue Type: Bug
>Reporter: Stian Soiland-Reyes
>Priority: Blocker
>  Labels: httpclient, jsonld
> Fix For: Jena 3.1.0
>
>
> Raised by 
> [Francois|http://mail-archives.apache.org/mod_mbox/jena-dev/201605.mbox/%3CB51A2FF9-23E8-460B-913D-43BAB7A07E29%40gmail.com%3E]:
> {code}
> public class TestJsonLDReader {
>   @Test public final void test() {
>   String jsonld = 
> "{\"@id\":\"_:b0\",\"@type\":\"http://schema.org/Person\",\"name\":\"John
> Doe\",\"@context\":\"http://schema.org/\"}";;
>   StringReader reader = new StringReader(jsonld);
>   Model m = ModelFactory.createDefaultModel();
>   m.read(reader, null, "JSON-LD");
>   m.write(System.out, "TURTLE");
>   }
> }
> {code}
> Fails with:
> {code}
> java.lang.NoSuchMethodError: 
> org.apache.http.impl.client.cache.CacheConfig.custom()Lorg/apache/http/impl/client/cache/CacheConfig$Builder;
>   at 
> com.github.jsonldjava.utils.JsonUtils.createDefaultHttpClient(JsonUtils.java:333)
>   at 
> com.github.jsonldjava.utils.JsonUtils.getDefaultHttpClient(JsonUtils.java:323)
>   at 
> com.github.jsonldjava.core.DocumentLoader.getHttpClient(DocumentLoader.java:84)
>   at 
> com.github.jsonldjava.core.DocumentLoader.fromURL(DocumentLoader.java:59)
>   at 
> com.github.jsonldjava.core.DocumentLoader.loadDocument(DocumentLoader.java:29)
>   at com.github.jsonldjava.core.Context.parse(Context.java:169)
>   at com.github.jsonldjava.core.Context.parse(Context.java:252)
>   at com.github.jsonldjava.core.JsonLdApi.expand(JsonLdApi.java:534)
>   at com.github.jsonldjava.core.JsonLdApi.expand(JsonLdApi.java:981)
>   at 
> com.github.jsonldjava.core.JsonLdProcessor.expand(JsonLdProcessor.java:146)
>   at 
> com.github.jsonldjava.core.JsonLdProcessor.toRDF(JsonLdProcessor.java:482)
>   at org.apache.jena.riot.lang.JsonLDReader.read$(JsonLDReader.java:143)
>   at org.apache.jena.riot.lang.JsonLDReader.read(JsonLDReader.java:64)
> {code}
> This is caused by a newer [JSONLD-Java 
> 0.8.2|https://github.com/jsonld-java/jsonld-java/blob/v0.8.2/pom.xml#L42] now 
> depending on 
> {code:xml}
>   4.5.1
>   4.4.4
> {code} 
> while we explicitly depend on a much older version:
> {code:xml}
> 
> 4.2.6
> 4.2.5
> {code}
> Issue JENA-576 discusses why HTTPClient was not upgraded.
> I suggest we try again to upgrade HTTPClient, even if this means also a newer 
> Solr. 
> A workaround would be to have an initialization to set 
> JsonUtils.setDefaultClient() with our own instance - however that would break 
> JSON-LD [Context JAR 
> caching|https://github.com/jsonld-java/jsonld-java#loading-contexts-from-classpathjar]
>  which I know we use in Taverna to avoid network traffic.
> As JSON-LD with external @context - e.g. with schema.org,  is the primary way 
> to use JSON-LD, then I think this should be a blocker for 3.1.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Jena 3.1.0 (2nd proposed candidate)

[Stian Soiland-Reyes]

Raised as https://issues.apache.org/jira/browse/JENA-1176

On 9 May 2016 at 13:33, Stian Soiland-Reyes  wrote:
> Yes, this error affects riot as well:
>
> stain@biggie:~/Downloads/apache-jena-3.1.0$ bin/riot --syntax=jsonld
> {"@context": "https://w3id.org/bundle/context";,
>  "id": "http://example.com/fred";,
>  "aggregates": "http://example.com/other";
> }
>
> Exception in thread "main" java.lang.NoSuchMethodError:
> org.apache.http.impl.client.cache.CacheConfig.custom()Lorg/apache/http/impl/client/cache/CacheConfig$Builder;
> at 
> com.github.jsonldjava.utils.JsonUtils.createDefaultHttpClient(JsonUtils.java:333)
> at 
> com.github.jsonldjava.utils.JsonUtils.getDefaultHttpClient(JsonUtils.java:323)
> at 
> com.github.jsonldjava.core.DocumentLoader.getHttpClient(DocumentLoader.java:84)
> at 
> com.github.jsonldjava.core.DocumentLoader.fromURL(DocumentLoader.java:59)
> at 
> com.github.jsonldjava.core.DocumentLoader.loadDocument(DocumentLoader.java:29)
> at com.github.jsonldjava.core.Context.parse(Context.java:169)
> at com.github.jsonldjava.core.Context.parse(Context.java:252)
> at com.github.jsonldjava.core.JsonLdApi.expand(JsonLdApi.java:534)
> at com.github.jsonldjava.core.JsonLdApi.expand(JsonLdApi.java:981)
> at 
> com.github.jsonldjava.core.JsonLdProcessor.expand(JsonLdProcessor.java:146)
> at 
> com.github.jsonldjava.core.JsonLdProcessor.toRDF(JsonLdProcessor.java:482)
> at org.apache.jena.riot.lang.JsonLDReader.read$(JsonLDReader.java:143)
> at org.apache.jena.riot.lang.JsonLDReader.read(JsonLDReader.java:83)
> at riotcmd.CmdLangParse.parseRIOT(CmdLangParse.java:286)
> at riotcmd.CmdLangParse.parseFile(CmdLangParse.java:202)
> at riotcmd.CmdLangParse.parseFile(CmdLangParse.java:184)
> at riotcmd.CmdLangParse.exec$(CmdLangParse.java:158)
> at riotcmd.CmdLangParse.exec(CmdLangParse.java:132)
> at jena.cmd.CmdMain.mainMethod(CmdMain.java:93)
> at jena.cmd.CmdMain.mainRun(CmdMain.java:58)
> at jena.cmd.CmdMain.mainRun(CmdMain.java:45)
> at riotcmd.riot.main(riot.java:34)
>
> On 9 May 2016 at 12:16, François-Paul Servant
>  wrote:
>> Hi,
>>
>>> I get another JSON-LD error with using the @context
>>> https://w3id.org/bundle/context that I need to check further what is
>>> the cause of that (it works fine with JSON-LD Playground).
>>>
>>> org.apache.jena.riot.RiotException: loading remote context failed:
>>> https://w3id.org/bundle/context
>>>at 
>>> org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.error(ErrorHandlerFactory.java:128)
>>>at org.apache.jena.riot.lang.JsonLDReader.read$(JsonLDReader.java:146)
>>>at org.apache.jena.riot.lang.JsonLDReader.read(JsonLDReader.java:83)
>>>at org.apache.jena.riot.RDFDataMgr.process(RDFDataMgr.java:861)
>>>at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:259)
>>>at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:245)
>>>
>>
>> I don’t know whether it is the same thing, but I noticed (working with 
>> 3.1.1-SNAPSHOT) that following test, that attempts to read a simple jsonld 
>> document with an external context
>>
>> public class TestJsonLDReader {
>>
>> @Test public final void test() {
>> String jsonld = 
>> "{\"@id\":\"_:b0\",\"@type\":\"http://schema.org/Person\",\"name\":\"John 
>> Doe\",\"@context\":\"http://schema.org/\"}";;
>> StringReader reader = new StringReader(jsonld);
>> Model m = ModelFactory.createDefaultModel();
>> m.read(reader, null, "JSON-LD");
>> m.write(System.out, "TURTLE");
>> }
>>
>> }
>>
>> gives:
>>
>> java.lang.NoSuchMethodError: 
>> org.apache.http.impl.client.cache.CacheConfig.custom()Lorg/apache/http/impl/client/cache/CacheConfig$Builder;
>> at 
>> com.github.jsonldjava.utils.JsonUtils.createDefaultHttpClient(JsonUtils.java:333)
>> at 
>> com.github.jsonldjava.utils.JsonUtils.getDefaultHttpClient(JsonUtils.java:323)
>> at 
>> com.github.jsonldjava.core.DocumentLoader.getHttpClient(DocumentLoader.java:84)
>> at 
>> com.github.jsonldjava.core.DocumentLoader.fromURL(DocumentLoader.java:59)
>> at 
>> com.github.jsonldjava.core.DocumentLoader.loadDocument(DocumentLoader.java:29)
>> at com.github.jsonldjava.core.Context.parse

[jira] [Created] (JENA-1176) JSON-LD @context parsing fails due to outdated HTTPClient

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created JENA-1176:
-

 Summary: JSON-LD @context parsing fails due to outdated HTTPClient
 Key: JENA-1176
 URL: https://issues.apache.org/jira/browse/JENA-1176
 Project: Apache Jena
  Issue Type: Bug
Reporter: Stian Soiland-Reyes
Priority: Blocker
 Fix For: Jena 3.1.0


Raised by 
[Francois|http://mail-archives.apache.org/mod_mbox/jena-dev/201605.mbox/%3CB51A2FF9-23E8-460B-913D-43BAB7A07E29%40gmail.com%3E]:

{code}
public class TestJsonLDReader {

@Test public final void test() {
String jsonld = 
"{\"@id\":\"_:b0\",\"@type\":\"http://schema.org/Person\",\"name\":\"John
Doe\",\"@context\":\"http://schema.org/\"}";;
StringReader reader = new StringReader(jsonld);
Model m = ModelFactory.createDefaultModel();
m.read(reader, null, "JSON-LD");
m.write(System.out, "TURTLE");
}
}
{code}

Fails with:

{code}

java.lang.NoSuchMethodError: 
org.apache.http.impl.client.cache.CacheConfig.custom()Lorg/apache/http/impl/client/cache/CacheConfig$Builder;
at 
com.github.jsonldjava.utils.JsonUtils.createDefaultHttpClient(JsonUtils.java:333)
at 
com.github.jsonldjava.utils.JsonUtils.getDefaultHttpClient(JsonUtils.java:323)
at 
com.github.jsonldjava.core.DocumentLoader.getHttpClient(DocumentLoader.java:84)
at 
com.github.jsonldjava.core.DocumentLoader.fromURL(DocumentLoader.java:59)
at 
com.github.jsonldjava.core.DocumentLoader.loadDocument(DocumentLoader.java:29)
at com.github.jsonldjava.core.Context.parse(Context.java:169)
at com.github.jsonldjava.core.Context.parse(Context.java:252)
at com.github.jsonldjava.core.JsonLdApi.expand(JsonLdApi.java:534)
at com.github.jsonldjava.core.JsonLdApi.expand(JsonLdApi.java:981)
at 
com.github.jsonldjava.core.JsonLdProcessor.expand(JsonLdProcessor.java:146)
at 
com.github.jsonldjava.core.JsonLdProcessor.toRDF(JsonLdProcessor.java:482)
at org.apache.jena.riot.lang.JsonLDReader.read$(JsonLDReader.java:143)
at org.apache.jena.riot.lang.JsonLDReader.read(JsonLDReader.java:64)
{code}

This is caused by a newer [JSONLD-Java 
0.8.2|https://github.com/jsonld-java/jsonld-java/blob/v0.8.2/pom.xml#L42] now 
depending on 

{code:xml}
4.5.1
4.4.4
{code} 

while we explicitly depend on a much older version:

{code:xml}

4.2.6
4.2.5
{code}

Issue JENA-576 discusses why HTTPClient was not upgraded.

I suggest we try again to upgrade HTTPClient, even if this means also a newer 
Solr. 

A workaround would be to have an initialization to set 
JsonUtils.setDefaultClient() with our own instance - however that would break 
JSON-LD [Context JAR 
caching|https://github.com/jsonld-java/jsonld-java#loading-contexts-from-classpathjar]
 which I know we use in Taverna to avoid network traffic.

As JSON-LD with external @context - e.g. with schema.org,  is the primary way 
to use JSON-LD, then I think this should be a blocker for 3.1.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [] Release Jena 3.1.0 (2nd proposed candidate)

[Stian Soiland-Reyes]

On 9 May 2016 at 12:54, Andy Seaborne  wrote:
>> BTW -
>> http://central.maven.org/maven2/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
>
> Jena does not use 2.8.1. The dependency is on 2.11.0.

Sorry, I picked the wrong 'latest' one by not sorting numerically in
my head.. :)

Official xerces 2.11.0 is neither an OSGi bundle.


> The jena-osgi-test module does run, even though it is still broken for use
> in the build.

> OSGi didn't work at 3.0.1 either as I understand PR#134

No, 3.0.1 jena-osgi was also broken because of the ServiceLoader issue.

> https://github.com/apache/jena/pull/134#issuecomment-209474708
> seems to discuss the Xerces issue.

Due to the Karaf issue you mention, then I suggest adding
org.apache.servicemix.bundles.xerces as an
informational true dependency.

See https://github.com/apache/jena/pull/140


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: [VOTE] Release Jena 3.1.0 (2nd proposed candidate)

[Stian Soiland-Reyes]

Reader.java:143)
> at org.apache.jena.riot.lang.JsonLDReader.read(JsonLDReader.java:64)
>
> It seems that there is a conflict between the version of http-client cache 
> used by JSON-LD java 0.8.2 (4.5.1), and the one that wants jena (4.2.6). Jena 
> seems to really want to choose its version, cf pom/xml:
>
> +   /*
> +  
> +    com.github.jsonld-java
> +jsonld-java
> +${ver.jsonldjava}
> +
> +  
> +commons-logging
> +commons-logging
> +  
> +  
> +  
> +org.apache.httpcomponents
> +httpclient-cache
> +  
> +  
> +org.apache.httpcomponents
> +httpclient
> +  
>
> Best,
>
> fps
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: [VOTE] Release Jena 3.1.0 (2nd proposed candidate)

[Stian Soiland-Reyes]

ndy Seaborne  wrote:
> Hi,
>
> Here is a vote on a release of Jena 3.1.0
> (with Fuseki 2.4.0 and Fuseki 1.4.0).
>
> This is the second proposed candidate for this release.
>
> This fixes, from the previous proposed candidate
> 1/ Presence of binaries in the source-release
> 2/ Jump in large size of binary downloads due to javadoc inclusion
>
> * Dependency changes:
>
> Upgrades:
>   jsonld-java : 2.8.2
>   jackson 2.6.3
>   slf4j 1.7.20
>   dexx collections 0.6
>
> Key features listed below.
>
> Everyone, not just committers, is invited to test and vote.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachejena-1012/
>
> Proposed dist/ area:
> https://dist.apache.org/repos/dist/dev/jena/
>
> Keys:
> https://svn.apache.org/repos/asf/jena/dist/KEYS
>
> Git commit (browser URL):
> http://git-wip-us.apache.org/repos/asf/jena/commit/e7ee6bb6
>
> Git Commit Hash:
> e7ee6bb69a5d7ce930a2529dd576a9ea209596a3
>
> Git Commit Tag:
> jena-3.1.0-rc3
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ]  0 Don't care
> [ ] -1 Don't release, because ...
>
> This vote will be open to at least
>
>  7th May 2016, 23:59 UTC
>
> If you expect to check the release but the 72 hour limit does not work for
> you, please email within the schedule above with an expected time and we can
> extend the vote period.
>
> Thanks,
>
> Andy
>
> Checking needed:
>
> + does everything work on Linux?
> + does everything work on MS Windows?
> + does everything work on OS X?
> + are the GPG signatures fine?
> + are the checksums correct?
> + is there a source archive?
> + can the source archive really be built?
> + is there a correct LICENSE and NOTICE file in each artifact
>   (both source and binary artifacts)?
> + does the NOTICE file contain all necessary attributions?
> + have any licenses of dependencies changed due to upgrades?
>if so have LICENSE and NOTICE been upgraded appropriately?
> + does the tag/commit in the SCM contain reproducible sources?
>
>
> ---
>
> Key features of the release:
>
> * In-memory txn dataset (Adam Soroka) (RC in 3.0.1)
>
> http://jena.staging.apache.org/documentation/rdf/datasets.html
>
> * Quads (Qihong Lin) (RC in 3.0.1)
>
> http://jena.staging.apache.org/documentation/query/construct-quad.html
>
> * DatasetGraphs & transactions integration
>
> * Alternative QueryParsers in jena-text
>
> * new module jena-cmds
> "jena.*"
>
> * Fuseki: Multiple service per file, shared datasets
>
> * Logging
> log4j marked 
>
> * New custom functions and aggregate functions
> Added:
> * afn:springf (contribution from Alessandro Seganti)
> * The XQuery/XPath Functions and Operators "math:" functions
> * Custom aggregates for stdev etc. (also STDEV etc as keywords).
>
> * FactoryRDF
> Parsing RDF now saves space by interning RDFTerms created
> during a each parser run.
>
> * OSGi fixes (Jaroslav Pullmann)
>
> * General maintenance: about 80 JIRA.
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

[jira] [Commented] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1169:
---

Draft XML also available at 
https://gist.github.com/stain/de648ed3670140a1d8c41476d4ef0f53

And HTML rendering from the XSLT at

https://cdn.rawgit.com/stain/de648ed3670140a1d8c41476d4ef0f53/raw/6a5771b9d5637e2ddfc8b64ebefcab28ca17b7a3/eccnmatrix.html

(do a Ctrl-F for Apache Jena)

Hoover over the "Controlled Source" links to see the "Why" text

> Is Jena US Export classified due to encryption in dependencies?
> ---
>
> Key: JENA-1169
> URL: https://issues.apache.org/jira/browse/JENA-1169
> Project: Apache Jena
>  Issue Type: Bug
>      Components: Build
>Reporter: Stian Soiland-Reyes
>
> Hi - apologies for finding this..
> I just noticed  on 
> http://www.apache.org/licenses/exports/   
> includes US export classified tools from ASF:
> Apache HttpComponents Core 4.0 and later
> Apache HttpComponents Client 4.0 and later
> Apache Hadoop 17.0 and later
> See also:
> http://www.apache.org/dev/crypto.html#faq-manyproducts
> We redistribute Apache HTTP Components in the Jena and Fuseki binary 
> distributions. We don't distribute Hadoop - we only link to it from Elephas.
> Reading ASF's FAQ it is not clear if we would need to be listed just from 
> having a  on such a classified item.
> Would we therefore also need to also declare Jena as classified? Or is the 
> transitivity broken because Jena only use the encryption (e.g. access 
> https:// JSON-LD contexts)? 
> (This transitivity thing could mean anyone in the US distributing software 
> using Jena would be US Export regulated. I hope I am wrong.. worth checking 
> with LEGAL I think)
> BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
> dependency:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E
> h2. Draft eccnmatrix.xml additions
> To be added to 
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
> and then published to http://www.apache.org/licenses/exports/
> See http://www.apache.org/dev/crypto.html#sources
> {code}
>  http://jena.apache.org";>
>   Apache Jena
>   Andy Seaborne
>   
> Apache Jena
> 
>   development
>   5D002
>href="https://git-wip-us.apache.org/repos/asf/jena.git";>
> ASF
> Use Apache HTTPComponents Client
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>href="http://archive.apache.org/dist/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
> 
> 
>   2.7.0-incubating and later
>   5D002
>   http://archive.apache.org/dist/jena/source/";>
> ASF
> Use Apache HTTPComponents Client
>   
>   http://archive.apache.org/dist/jena/binaries/";>
> ASF
> Include Apache HTTPComponents Client
>   
> 
>   
>   
> Apache Jena Fuseki
> 
>   development
>   5D002
>href="https://git-wip-us.apache.org/repos/asf/jena.git";>
> ASF
> Use Apache HTTPComponents Client, Apache Shiro
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>href="http://archive.apache.org/dist/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>   http://archive.apache.org/dist/shiro/";>
> ASF
> Designed for use with Java Cryptography Extensions (JCE)
>   
> 
> 
>   0.2.1-incubating and later
>   5D002
>   http://archive.apache.org/dist/jena/source/";>
> ASF
> Use Apache HTTPComponents Client, Apache Shiro
>   
>   http://archive.apache.org/dist/jena/binaries/";>
> ASF
> Include Apache HTTPComponents, Apache Shiro, Apache Solr, 
> Jetty
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
>   

[jira] [Updated] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes updated JENA-1169:
--
Description: 
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only use the encryption (e.g. access https:// 
JSON-LD contexts)? 

(This transitivity thing could mean anyone in the US distributing software 
using Jena would be US Export regulated. I hope I am wrong.. worth checking 
with LEGAL I think)


BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
dependency:

http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E



h2. Draft eccnmatrix.xml additions

To be added to 
https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
and then published to http://www.apache.org/licenses/exports/

See http://www.apache.org/dev/crypto.html#sources


{code:xml}
 http://jena.apache.org";>
  Apache Jena
  Andy Seaborne
  
Apache Jena

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  


  2.7.0-incubating and later
  5D002
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents Client
  

  
  
Apache Jena Fuseki

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  


  0.2.1-incubating and later
  5D002
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents, Apache Shiro, Apache Solr, 
Jetty
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  
  http://www.apache.org/dist/lucene/solr/";>
ASF
Designed for use with the Apache Tika API in the 
contrib/extraction libraries
  
  http://eclipse.org/jetty";>
The Eclipse Foundation
SSL library for Jetty
  

  

{code}



  was:
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jen

[jira] [Updated] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes updated JENA-1169:
--
Description: 
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only use the encryption (e.g. access https:// 
JSON-LD contexts)? 

(This transitivity thing could mean anyone in the US distributing software 
using Jena would be US Export regulated. I hope I am wrong.. worth checking 
with LEGAL I think)


BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
dependency:

http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E



h2. Draft eccnmatrix.xml additions

To be added to 
https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
and then published to http://www.apache.org/licenses/exports/

See http://www.apache.org/dev/crypto.html#sources


{code}
 http://jena.apache.org";>
  Apache Jena
  Andy Seaborne
  
Apache Jena

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  


  2.7.0-incubating and later
  5D002
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents Client
  

  
  
Apache Jena Fuseki

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  


  0.2.1-incubating and later
  5D002
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents, Apache Shiro, Apache Solr, 
Jetty
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  
  http://www.apache.org/dist/lucene/solr/";>
ASF
Designed for use with the Apache Tika API in the 
contrib/extraction libraries
  
  http://eclipse.org/jetty";>
The Eclipse Foundation
SSL library for Jetty
  

  

{code}



  was:
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only

[jira] [Commented] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1169:
---

Draft BIS notice email:

{quote}
---EMAIL HEADER---
To: cr...@bis.doc.gov, e...@nsa.gov, web_s...@bis.doc.gov
Cc: legal-arch...@apache.org, {applicable project list}
Subject: TSU NOTIFICATION - Encryption
---EMAIL BODY---
SUBMISSION TYPE:  TSU

SUBMITTED BY: Andy Seaborne

SUBMITTED FOR:The Apache Software Foundation

POINT OF CONTACT: Secretary, The Apache Software Foundation

FAX:  +1-919-573-9199

MANUFACTURER(S):  The Apache Software Foundation, The Eclipse Foundation

PRODUCT NAME/MODEL #: Apache Jena, Apache Jena Fuseki

ECCN: 5D002

NOTIFICATION: http://www.apache.org/licenses/exports/


{quote}

> Is Jena US Export classified due to encryption in dependencies?
> ---
>
> Key: JENA-1169
> URL: https://issues.apache.org/jira/browse/JENA-1169
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Build
>    Reporter: Stian Soiland-Reyes
>
> Hi - apologies for finding this..
> I just noticed  on 
> http://www.apache.org/licenses/exports/   
> includes US export classified tools from ASF:
> Apache HttpComponents Core 4.0 and later
> Apache HttpComponents Client 4.0 and later
> Apache Hadoop 17.0 and later
> See also:
> http://www.apache.org/dev/crypto.html#faq-manyproducts
> We redistribute Apache HTTP Components in the Jena and Fuseki binary 
> distributions. We don't distribute Hadoop - we only link to it from Elephas.
> Reading ASF's FAQ it is not clear if we would need to be listed just from 
> having a  on such a classified item.
> Would we therefore also need to also declare Jena as classified? Or is the 
> transitivity broken because Jena only use the encryption (e.g. access 
> https:// JSON-LD contexts)? 
> (This transitivity thing could mean anyone in the US distributing software 
> using Jena would be US Export regulated. I hope I am wrong.. worth checking 
> with LEGAL I think)
> BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
> dependency:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E
> h2. Draft eccnmatrix.xml additions
> To be added to 
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
> and then published to http://www.apache.org/licenses/exports/
> See http://www.apache.org/dev/crypto.html#sources
> {code}
>  http://jena.apache.org";>
>   Apache Jena
>   Andy Seaborne
>   
> Apache Jena
> 
>   development
>   5D002
>href="https://git-wip-us.apache.org/repos/asf/jena.git";>
> ASF
> Use Apache HTTPComponents Client
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>href="http://archive.apache.org/dist/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
> 
> 
>   2.7.0-incubating and later
>   http://archive.apache.org/dist/jena/source/";>
> ASF
> Use Apache HTTPComponents Client
>   
>   http://archive.apache.org/dist/jena/binaries/";>
> ASF
> Include Apache HTTPComponents Client
>   
> 
>   
>   
> Apache Jena Fuseki
> 
>   development
>   5D002
>href="https://git-wip-us.apache.org/repos/asf/jena.git";>
> ASF
> Use Apache HTTPComponents Client, Apache Shiro
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>href="http://archive.apache.org/dist/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>   http://archive.apache.org/dist/shiro/";>
> ASF
> Designed for use with Java Cryptography Extensions (JCE)
>   
> 
> 
>   0.2.1-incubating and later
>   http://archive.apache.org/dist/jena/source/";>
> ASF
> Use Apache HTTPComponents Client, Apache Shiro
>   
>

[jira] [Commented] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1169:
---

I added a draft XML to be added - please review and then I can commit it and 
you can click the CMS publish button.

Basically I split between Jena and Fuseki. I didn't make a separate Product 
Jena-arq 2.9.0-incubating - and I didn't make two separate versions depending 
on when Solr was added to Fuseki (I think it was in one of the 0.x releases)

Note that the "Why" reasoning is different for the source and binary 
distributions - the source is only restricted based on the encryption 
functionality it USES (e.g. use HTTP Components and Apache Shiro - but we don't 
use the encryption facility of say), while the binary also is restricted based 
on hat is bundled (e.g. Jetty)

I did not list Hadoop as we don't re-distribute Hadoop and Elephas don't use 
the encryption facility in Hadoop (?).

If you agree on this list then I'll prepare the README.md changes.. which is 
probably a bit easier to understand for people :)

> Is Jena US Export classified due to encryption in dependencies?
> ---
>
> Key: JENA-1169
> URL: https://issues.apache.org/jira/browse/JENA-1169
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Build
>Reporter: Stian Soiland-Reyes
>
> Hi - apologies for finding this..
> I just noticed  on 
> http://www.apache.org/licenses/exports/   
> includes US export classified tools from ASF:
> Apache HttpComponents Core 4.0 and later
> Apache HttpComponents Client 4.0 and later
> Apache Hadoop 17.0 and later
> See also:
> http://www.apache.org/dev/crypto.html#faq-manyproducts
> We redistribute Apache HTTP Components in the Jena and Fuseki binary 
> distributions. We don't distribute Hadoop - we only link to it from Elephas.
> Reading ASF's FAQ it is not clear if we would need to be listed just from 
> having a  on such a classified item.
> Would we therefore also need to also declare Jena as classified? Or is the 
> transitivity broken because Jena only use the encryption (e.g. access 
> https:// JSON-LD contexts)? 
> (This transitivity thing could mean anyone in the US distributing software 
> using Jena would be US Export regulated. I hope I am wrong.. worth checking 
> with LEGAL I think)
> BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
> dependency:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E
> h2. Draft eccnmatrix.xml additions
> To be added to 
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
> and then published to http://www.apache.org/licenses/exports/
> See http://www.apache.org/dev/crypto.html#sources
> {code}
>  http://jena.apache.org";>
>   Apache Jena
>   Andy Seaborne
>   
> Apache Jena
> 
>   development
>   5D002
>href="https://git-wip-us.apache.org/repos/asf/jena.git";>
> ASF
> Use Apache HTTPComponents Client
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>href="http://archive.apache.org/dist/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
> 
> 
>   2.7.0-incubating and later
>   http://archive.apache.org/dist/jena/source/";>
> ASF
> Use Apache HTTPComponents Client
>   
>   http://archive.apache.org/dist/jena/binaries/";>
> ASF
> Include Apache HTTPComponents Client
>   
> 
>   
>   
> Apache Jena Fuseki
> 
>   development
>   5D002
>href="https://git-wip-us.apache.org/repos/asf/jena.git";>
> ASF
> Use Apache HTTPComponents Client, Apache Shiro
>   
>href="http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>href="http://archive.apache.org/dist/httpcomponents/httpcore/";>
> ASF
> Designed for use with Java Secure Socket Extension (JSSE)
>   
>   http://archive.apache.org/dist/shiro/";>
> ASF
> Designed for

[jira] [Updated] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes updated JENA-1169:
--
Description: 
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only use the encryption (e.g. access https:// 
JSON-LD contexts)? 

(This transitivity thing could mean anyone in the US distributing software 
using Jena would be US Export regulated. I hope I am wrong.. worth checking 
with LEGAL I think)


BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
dependency:

http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E



h2. Draft eccnmatrix.xml additions

To be added to 
https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
and then published to http://www.apache.org/licenses/exports/

See http://www.apache.org/dev/crypto.html#sources


{code}
 http://jena.apache.org";>
  Apache Jena
  Andy Seaborne
  
Apache Jena

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  


  2.7.0-incubating and later
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents Client
  

  
  
Apache Jena Fuseki

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  


  0.2.1-incubating and later
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents, Apache Shiro, Apache Solr, 
Jetty
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  
  http://www.apache.org/dist/lucene/solr/";>
ASF
Designed for use with the Apache Tika API in the 
contrib/extraction libraries
  
  http://eclipse.org/jetty";>
The Eclipse Foundation
SSL library for Jetty
  

  

{code}



  was:
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only use the encryption (e.

[jira] [Updated] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes updated JENA-1169:
--
Description: 
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only use the encryption (e.g. access https:// 
JSON-LD contexts)? 

(This transitivity thing could mean anyone in the US distributing software 
using Jena would be US Export regulated. I hope I am wrong.. worth checking 
with LEGAL I think)


BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
dependency:

http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E



.h2 Draft eccnmatrix.xml additions

To be added to 
https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
and then published to http://www.apache.org/licenses/exports/

See http://www.apache.org/dev/crypto.html#sources


{code}
 http://jena.apache.org";>
  Apache Jena
  Andy Seaborne
  
Apache Jena

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  


  2.7.0-incubating and later
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents Client
  

  
  
Apache Jena Fuseki

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  


  0.2.1-incubating and later
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents, Apache Shiro, Apache Solr, 
Jetty
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  
  http://www.apache.org/dist/lucene/solr/";>
ASF
Designed for use with the Apache Tika API in the 
contrib/extraction libraries
  
  http://eclipse.org/jetty";>
The Eclipse Foundation
SSL library for Jetty
  

  

{code}



  was:
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only use the encryption (e.

[jira] [Updated] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes updated JENA-1169:
--
Description: 
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only use the encryption (e.g. access https:// 
JSON-LD contexts)? 

(This transitivity thing could mean anyone in the US distributing software 
using Jena would be US Export regulated. I hope I am wrong.. worth checking 
with LEGAL I think)


BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
dependency:

http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E



## Draft eccnmatrix.xml additions

Add to 

{code}
 http://jena.apache.org";>
  Apache Jena
  Andy Seaborne
  
Apache Jena

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  


  2.7.0-incubating and later
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents Client
  

  
  
Apache Jena Fuseki

  development
  5D002
  https://git-wip-us.apache.org/repos/asf/jena.git";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  


  0.2.1-incubating and later
  http://archive.apache.org/dist/jena/source/";>
ASF
Use Apache HTTPComponents Client, Apache Shiro
  
  http://archive.apache.org/dist/jena/binaries/";>
ASF
Include Apache HTTPComponents, Apache Shiro, Apache Solr, 
Jetty
  
  http://svn.apache.org/repos/asf/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/httpcomponents/httpcore/";>
ASF
Designed for use with Java Secure Socket Extension (JSSE)
  
  http://archive.apache.org/dist/shiro/";>
ASF
Designed for use with Java Cryptography Extensions (JCE)
  
  http://www.apache.org/dist/lucene/solr/";>
ASF
Designed for use with the Apache Tika API in the 
contrib/extraction libraries
  
  http://eclipse.org/jetty";>
The Eclipse Foundation
SSL library for Jetty
  

  

{code}



  was:
Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only use the encryption (e.g. access https:// 
JSON-LD contexts)? 

(This transitivity thing could mean anyone in the US distributing software 
using Jena would be US Export regulated. I hope I am wrong.. worth checking 
with LEGAL I think)


BTW this was 

Fwd: [jira] [Commented] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes]

OK, having just done this for Taverna I can draft the XML and readme
changes to be added, and then Jena PMC Chair (you!) :) can send the formal
email.

Should we delay 3.1.0 for this?
-- Forwarded message --
From: "Andy Seaborne (JIRA)" 
Date: 6 May 2016 1:45 p.m.
Subject: [jira] [Commented] (JENA-1169) Is Jena US Export classified due to
encryption in dependencies?
To: 
Cc:


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

Andy Seaborne commented on JENA-1169:
-

Thanks for pushing forward in this.

I think we should register Jena regardless of whether some reading of the
requirements means Jena may or may not be included.

There have been, in the lifetime of the TLP, two enquiries about ECCN so
adding Jena to the registrations makes sense to me.

(Note that the responsibility for anything using Jena downstream does
reside with the downstream integrator.)


> Is Jena US Export classified due to encryption in dependencies?
> ---
>
> Key: JENA-1169
> URL: https://issues.apache.org/jira/browse/JENA-1169
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Build
>Reporter: Stian Soiland-Reyes
>
> Hi - apologies for finding this..
> I just noticed  on
> http://www.apache.org/licenses/exports/
> includes US export classified tools from ASF:
> Apache HttpComponents Core 4.0 and later
> Apache HttpComponents Client 4.0 and later
> Apache Hadoop 17.0 and later
> See also:
> http://www.apache.org/dev/crypto.html#faq-manyproducts
> We redistribute Apache HTTP Components in the Jena and Fuseki binary
distributions. We don't distribute Hadoop - we only link to it from Elephas.
> Reading ASF's FAQ it is not clear if we would need to be listed just from
having a  on such a classified item.
> Would we therefore also need to also declare Jena as classified? Or is
the transitivity broken because Jena only use the encryption (e.g. access
https:// JSON-LD contexts)?
> (This transitivity thing could mean anyone in the US distributing
software using Jena would be US Export regulated. I hope I am wrong.. worth
checking with LEGAL I think)
> BTW this was discussed in 2011 - but I believe we since removed
BouncyCastle dependency:
>
http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes edited comment on JENA-1169 at 5/5/16 3:33 PM:
---

Discussion on LEGAL-250 seems to show that if you bundle an "encryption item", 
then you must register.

You are however [exempt from 
registration|https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three]
 at all if:

{quote}
* (a) The primary function or set of functions is not any of the following:
** (1) "Information security";
** (2) A computer, including operating systems, parts and components 
therefor;
** (3) Sending, receiving or storing information (except in support of 
entertainment, mass commercial broadcasts, digital rights management or medical 
records management); or
** (4) Networking (includes operation, administration, management and 
provisioning);
{quote}

Unfortunately Jena falls through this exemption on (3) as Jena has a set of 
functions that includes sending information (Fuseki) and storing information 
(TDB store). And although those are not encrypted - that would mean we have to 
do a registration of the "encryption functionalities" we use (compile against) 
and "encryption items" we include (distribute). 

In terms of "using any encryption functionality" there would be the use of 
'riot' and RDFDataMgr with https URLs (using Java Secure Socket Extension 
(JSSE)). Bindings to Hadoop is fine - that is not "using encryption 
functionality"

The biggie is that the binary distributions include HTTPComponents, which is 
itself an "encryption item".


was (Author: stain):
Discussion on LEGAL-250 seems to show that if you bundle an "encryption item", 
then you are registered.

You are however [exempt from 
registration|https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three]
 at all if:

{quote}
* (a) The primary function or set of functions is not any of the following:
** (1) "Information security";
** (2) A computer, including operating systems, parts and components 
therefor;
** (3) Sending, receiving or storing information (except in support of 
entertainment, mass commercial broadcasts, digital rights management or medical 
records management); or
** (4) Networking (includes operation, administration, management and 
provisioning);
{quote}

Unfortunately Jena falls through this exemption on (3) as Jena has a set of 
functions that includes sending information (Fuseki) and storing information 
(TDB store). And although those are not encrypted - that would mean we have to 
do a registration of the "encryption functionalities" we use (compile against) 
and "encryption items" we include (distribute). 

In terms of "using any encryption functionality" there would be the use of 
'riot' and RDFDataMgr with https URLs (using Java Secure Socket Extension 
(JSSE)). Bindings to Hadoop is fine - that is not "using encryption 
functionality"

The biggie is that the binary distributions include HTTPComponents, which is 
itself an "encryption item".

> Is Jena US Export classified due to encryption in dependencies?
> ---
>
> Key: JENA-1169
>     URL: https://issues.apache.org/jira/browse/JENA-1169
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Build
>Reporter: Stian Soiland-Reyes
>
> Hi - apologies for finding this..
> I just noticed  on 
> http://www.apache.org/licenses/exports/   
> includes US export classified tools from ASF:
> Apache HttpComponents Core 4.0 and later
> Apache HttpComponents Client 4.0 and later
> Apache Hadoop 17.0 and later
> See also:
> http://www.apache.org/dev/crypto.html#faq-manyproducts
> We redistribute Apache HTTP Components in the Jena and Fuseki binary 
> distributions. We don't distribute Hadoop - we only link to it from Elephas.
> Reading ASF's FAQ it is not clear if we would need to be listed just from 
> having a  on such a classified item.
> Would we therefore also need to also declare Jena as classified? Or is the 
> transitivity broken because Jena only use the encryption (e.g. access 
> https:// JSON-LD contexts)? 
> (This transitivity thing could mean anyone in the US distributing software 
> using Jena would be US Export regulated. I hope I am wrong.. worth checking 
> with LEGAL I think)
> BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
> dependency:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1169:
---

Discussion on LEGAL-250 seems to show that if you bundle an "encryption item", 
then you are registered.

You are however [exempt from 
registration|https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three]
 at all if:

{quote}
* (a) The primary function or set of functions is not any of the following:
** (1) "Information security";
** (2) A computer, including operating systems, parts and components 
therefor;
** (3) Sending, receiving or storing information (except in support of 
entertainment, mass commercial broadcasts, digital rights management or medical 
records management); or
** (4) Networking (includes operation, administration, management and 
provisioning);
{quote}

Unfortunately Jena falls through this exemption on (3) as Jena has a set of 
functions that includes sending information (Fuseki) and storing information 
(TDB store). And although those are not encrypted - that would mean we have to 
do a registration of the "encryption functionalities" we use (compile against) 
and "encryption items" we include (distribute). 

In terms of "using any encryption functionality" there would be the use of 
'riot' and RDFDataMgr with https URLs (using Java Secure Socket Extension 
(JSSE)). Bindings to Hadoop is fine - that is not "using encryption 
functionality"

The biggie is that the binary distributions include HTTPComponents, which is 
itself an "encryption item".

> Is Jena US Export classified due to encryption in dependencies?
> ---
>
> Key: JENA-1169
> URL: https://issues.apache.org/jira/browse/JENA-1169
>     Project: Apache Jena
>  Issue Type: Bug
>  Components: Build
>Reporter: Stian Soiland-Reyes
>
> Hi - apologies for finding this..
> I just noticed  on 
> http://www.apache.org/licenses/exports/   
> includes US export classified tools from ASF:
> Apache HttpComponents Core 4.0 and later
> Apache HttpComponents Client 4.0 and later
> Apache Hadoop 17.0 and later
> See also:
> http://www.apache.org/dev/crypto.html#faq-manyproducts
> We redistribute Apache HTTP Components in the Jena and Fuseki binary 
> distributions. We don't distribute Hadoop - we only link to it from Elephas.
> Reading ASF's FAQ it is not clear if we would need to be listed just from 
> having a  on such a classified item.
> Would we therefore also need to also declare Jena as classified? Or is the 
> transitivity broken because Jena only use the encryption (e.g. access 
> https:// JSON-LD contexts)? 
> (This transitivity thing could mean anyone in the US distributing software 
> using Jena would be US Export regulated. I hope I am wrong.. worth checking 
> with LEGAL I think)
> BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
> dependency:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-1169) Is Jena US Export classified due to encryption in dependencies?

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes updated JENA-1169:
--
Summary: Is Jena US Export classified due to encryption in dependencies?  
(was: Is Jena US Export classified due to encryption?)

> Is Jena US Export classified due to encryption in dependencies?
> ---
>
> Key: JENA-1169
> URL: https://issues.apache.org/jira/browse/JENA-1169
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Build
>        Reporter: Stian Soiland-Reyes
>
> Hi - apologies for finding this..
> I just noticed  on 
> http://www.apache.org/licenses/exports/   
> includes US export classified tools from ASF:
> Apache HttpComponents Core 4.0 and later
> Apache HttpComponents Client 4.0 and later
> Apache Hadoop 17.0 and later
> See also:
> http://www.apache.org/dev/crypto.html#faq-manyproducts
> We redistribute Apache HTTP Components in the Jena and Fuseki binary 
> distributions. We don't distribute Hadoop - we only link to it from Elephas.
> Reading ASF's FAQ it is not clear if we would need to be listed just from 
> having a  on such a classified item.
> Would we therefore also need to also declare Jena as classified? Or is the 
> transitivity broken because Jena only use the encryption (e.g. access 
> https:// JSON-LD contexts)? 
> (This transitivity thing could mean anyone in the US distributing software 
> using Jena would be US Export regulated. I hope I am wrong.. worth checking 
> with LEGAL I think)
> BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
> dependency:
> http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1169) Is Jena US Export classified due to encryption?

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created JENA-1169:
-

 Summary: Is Jena US Export classified due to encryption?
 Key: JENA-1169
 URL: https://issues.apache.org/jira/browse/JENA-1169
 Project: Apache Jena
  Issue Type: Bug
  Components: Build
Reporter: Stian Soiland-Reyes


Hi - apologies for finding this..


I just noticed  on 
http://www.apache.org/licenses/exports/   

includes US export classified tools from ASF:

Apache HttpComponents Core 4.0 and later
Apache HttpComponents Client 4.0 and later
Apache Hadoop 17.0 and later

See also:

http://www.apache.org/dev/crypto.html#faq-manyproducts


We redistribute Apache HTTP Components in the Jena and Fuseki binary 
distributions. We don't distribute Hadoop - we only link to it from Elephas.

Reading ASF's FAQ it is not clear if we would need to be listed just from 
having a  on such a classified item.

Would we therefore also need to also declare Jena as classified? Or is the 
transitivity broken because Jena only use the encryption (e.g. access https:// 
JSON-LD contexts)? 

(This transitivity thing could mean anyone in the US distributing software 
using Jena would be US Export regulated. I hope I am wrong.. worth checking 
with LEGAL I think)


BTW this was discussed in 2011 - but I believe we since removed BouncyCastle 
dependency:

http://mail-archives.apache.org/mod_mbox/jena-dev/201108.mbox/%3c4e3ff7e8.1060...@epimorphics.com%3E





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1161) riot cmdline uses wrong base when parsing Turtle over http

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1161:
---

Confirm that this was fixed in 
https://repository.apache.org/content/groups/snapshots/org/apache/jena/apache-jena/3.1.0-SNAPSHOT/apache-jena-3.1.0-20160408.103050-77.tar.gz

> riot cmdline uses wrong base when parsing Turtle over http
> --
>
> Key: JENA-1161
> URL: https://issues.apache.org/jira/browse/JENA-1161
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Cmd line tools
>Affects Versions: Jena 3.0.1
>    Reporter: Stian Soiland-Reyes
>Assignee: Andy Seaborne
> Fix For: Jena 3.1.0
>
>
> Parsing a Turtle file served over http:// or https:// which has got no @base, 
> and uses relative IRI references, wrongly uses the current directory in 
> file:/// as a base.
> The command line
> {code}
> stain@biggie:/tmp$ riot 
> https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl
> {code}
> where that URL returns Content-Type: text/turtle;charset=utf-8 with the body:
> {code}
> @prefix : <#> .
> <> :a <#test> .
> {code}
> is wrongly parsed by the riot command line tool to be relative to the current 
> directory:
> {code}
> 
>  
> 
>  
> 
>  .
> {code}
> The expected output would be the same as supplying the same URI as a --base:
> {code}
> stain@biggie:/tmp$ riot --base 
> https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl
>  
> https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl
> <https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl>
>  
> <https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl#a>
>  
> <https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl#test>
>  .
> {code}
> (except if a Content-Location header is provided, or HTTP redirection has 
> been followed - in which case the result of that should be used as base)
> Relevant specs:
> https://www.w3.org/TR/turtle/#sec-iri-references
> https://www.ietf.org/rfc/rfc3986 section 5.1 and 5.2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1161) riot cmdline uses wrong base when parsing Turtle over http

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created JENA-1161:
-

 Summary: riot cmdline uses wrong base when parsing Turtle over http
 Key: JENA-1161
 URL: https://issues.apache.org/jira/browse/JENA-1161
 Project: Apache Jena
  Issue Type: Bug
  Components: Cmd line tools
Affects Versions: Jena 3.0.1
Reporter: Stian Soiland-Reyes


Parsing a Turtle file served over http:// or https:// which has got no @base, 
and uses relative IRI references, wrongly uses the current directory in 
file:/// as a base.

The command line
{code}
stain@biggie:/tmp$ riot 
https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl
{code}

where that URL returns Content-Type: text/turtle;charset=utf-8 with the body:

{code}
@prefix : <#> .
<> :a <#test> .
{code}

is wrongly parsed by the riot command line tool to be relative to the current 
directory:

{code}

 

 

 .
{code}

The expected output would be the same as supplying the same URI as a --base:

{code}
stain@biggie:/tmp$ riot --base 
https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl
 
https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl
<https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl>
 
<https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl#a>
 
<https://cdn.rawgit.com/stain/3d49908d790c5678faee302ba17f4a43/raw/bceb24ee6bfcaa60c4508779bc5f09ec367876f1/nobase.ttl#test>
 .
{code}

(except if a Content-Location header is provided, or HTTP redirection has been 
followed - in which case the result of that should be used as base)

Relevant specs:

https://www.w3.org/TR/turtle/#sec-iri-references
https://www.ietf.org/rfc/rfc3986 section 5.1 and 5.2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1139) jena-osgi does not initialize all modules

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1139:
---

I can confirm that 3.1.0-SNAPSHOT fixes the stacktrace we got in TAVERNA-892. 
Thanks!

> jena-osgi does not initialize all modules
> -
>
> Key: JENA-1139
> URL: https://issues.apache.org/jira/browse/JENA-1139
> Project: Apache Jena
>  Issue Type: Bug
>  Components: OSGi
>Affects Versions: Jena 3.0.1
>    Reporter: Stian Soiland-Reyes
>Assignee: Andy Seaborne
> Fix For: Jena 3.1.0
>
> Attachments: Screen Shot 2016-02-11 at 10.02.50.png
>
>
> As discovered in TAVERNA-892 the jena-osgi of Jena 3.0.1
> seems to have not merged correctly 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> which breaks the new Jena initialization - only TDB is initialized - but TDB 
> depends on ARQ already being initialized (to get its context).
> {code}
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ unzip 
> ./3.0.1/jena-osgi-3.0.1.jar 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> Archive:  ./3.0.1/jena-osgi-3.0.1.jar
>   inflating: META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle  
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ cat 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> org.apache.jena.tdb.sys.InitTDB
> {code}
> So basically only the last JenaSubsystemLifecycle file survives when  shading 
> jena-core, jena-arq, jena-tdb, jena-iri with Embed-Dependency and inline=true.
> The equivalent of the Maven Shade plugin's ServicesResourceTransformer would 
> be able to merge these.
> https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer
> but I'm not sure how this can be done with the bundle plugin.  I guess it 
> could be overridden with its own src/main/resources/META-INF/services/ file 
> in jena-osgi as well - but then it needs maintenance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Commented] (JENA-1139) jena-osgi does not initialize all modules

[Stian Soiland-Reyes]

My apologies about the LocationLock, I did not commit any change to that.
Perhaps my branch got out of date with master (Github didn't indicate
anything weird so I didn't check properly)

Thanks for accepting the little workaround, I think it is the easiest
option for now rather than fight Maven to do the wrong thing. I'll test the
SNAPSHOT.
On 10 Feb 2016 19:45, "ASF GitHub Bot (JIRA)"  wrote:

>
> [
> https://issues.apache.org/jira/browse/JENA-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15141430#comment-15141430
> ]
>
> ASF GitHub Bot commented on JENA-1139:
> --
>
> Github user afs commented on the pull request:
>
> https://github.com/apache/jena/pull/126#issuecomment-182525289
>
> I tried to pull this and got changes to tdb/base/file/LocationLock
> (possibly no actual change). What's happening?
>
>
> > jena-osgi does not initialize all modules
> > -
> >
> > Key: JENA-1139
> > URL: https://issues.apache.org/jira/browse/JENA-1139
> > Project: Apache Jena
> >      Issue Type: Bug
> >  Components: OSGi
> >Affects Versions: Jena 3.0.1
> >Reporter: Stian Soiland-Reyes
> >
> > As discovered in TAVERNA-892 the jena-osgi of Jena 3.0.1
> > seems to have not merged correctly
> > META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> > which breaks the new Jena initialization - only TDB is initialized - but
> TDB depends on ARQ already being initialized (to get its context).
> > {code}
> > stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ unzip
> ./3.0.1/jena-osgi-3.0.1.jar
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> > Archive:  ./3.0.1/jena-osgi-3.0.1.jar
> >   inflating:
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> > stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ cat
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> > org.apache.jena.tdb.sys.InitTDB
> > {code}
> > So basically only the last JenaSubsystemLifecycle file survives when
> shading jena-core, jena-arq, jena-tdb, jena-iri with Embed-Dependency and
> inline=true.
> > The equivalent of the Maven Shade plugin's ServicesResourceTransformer
> would be able to merge these.
> >
> https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer
> > but I'm not sure how this can be done with the bundle plugin.  I guess
> it could be overridden with its own src/main/resources/META-INF/services/
> file in jena-osgi as well - but then it needs maintenance.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Re: [jira] [Commented] (JENA-1139) jena-osgi does not initialize all modules

[Stian Soiland-Reyes]

Looking at Maven downloads is not fair as most OSGi users are not using
Maven as build system, but use OSGi directly, e g. with Eclipse, and get
their bundles in various ways.

One example of an OSGi project who uses owlapi and sesame (but not Jena I
think) is Protégé the ontology editor. In Taverna we use OSGi with Maven
build, because we don't want to move out of Maven's ecosystem (and changing
build system is a big job ;)

If you compare Maven jars now to 5 years ago I think you will find a
significant increase in projects that are also OSGi bundles (at
mvnrepository.com look for type BUNDLE). The reason is simple, it is
usually just a matter of adding the right META-INF settings which don't
impact "regular" Java/Maven users .

Agree that there should not be any big reason to not use the bundle setting
on all of jena-libs - the maven-bundle-plugin does a good enough job when
you avoid the workarounds.

Two things holding back is xerces and xmlapi, but we could shade them as we
do with guava (thus calming the worry about using impl. classed in xerces)
or add their Jars to jena-core as is done in jena-osgi currently. Shading
will probably avoid most conflicts as shown in Clerezza-Jena case.

Another is the odd Class.forName, if we still have any, from jena-core to
jena-arq. This should be changed anyway as it is not really good practice.

My apologies for not maintaining the jena-osgi-test - that particular
testing approach was new to me as well so I don't know how to debug it. It
was mainly needed to verify that the jena-osgi repackaging didn't break
anything (e.g. this bug).

One last thing is that jena-arq etc depend on httpclient, which has a
similar separate httpclient-osgi variant, which unfortunately in Maven
depends on the regular httpclient JARs (without our scope:provided trick) -
jena-osgi uses ignores to avoid downstream OSGi-Maven users from getting
duplicate httpclients.

It would be possible to switch to use the httpclient-osgi Maven dependency
instead all over in Jena, but this could surprise existing Maven users who
could end up with duplicate httpclient implementations om their classpath
in different versions if other dependencies use httpclient.

This is not a large issue as I said most OSGi projects don't rely on Maven
dependency transitivity blindly (and they could always ignore locally those
extra dependencies).

Assuming we change jena-core/tdb/arq/iri to be bundles themselves but still
depending on regular httpclient, perhaps one way to simplify Jena use for
OSGi-Maven users is for jena-osgi to remain as a dependency marker pom
only, with appropriate .

But this thread should be tracked as a new Jira issue! :))
On 11 Feb 2016 16:44, "A. Soroka (JIRA)"  wrote:

>
> [
> https://issues.apache.org/jira/browse/JENA-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142908#comment-15142908
> ]
>
> A. Soroka commented on JENA-1139:
> -
>
> The {{jena-osgi}} bundle, but only to avoid the kind of thing that went on
> here: CLEREZZA-1004, and because we will not commit our users to a specific
> OSGi framework/container. We would certainly rather just pull in ordinary
> Jena JARs (that happen to include the OSGi metadata). Is there some reason
> I am missing that we can't equip those JARs with said metadata? Is it just
> a matter of who's got the time?
>
> > jena-osgi does not initialize all modules
> > -
> >
> > Key: JENA-1139
> > URL: https://issues.apache.org/jira/browse/JENA-1139
> > Project: Apache Jena
> >  Issue Type: Bug
> >  Components: OSGi
> >Affects Versions: Jena 3.0.1
> >Reporter: Stian Soiland-Reyes
> >Assignee: Andy Seaborne
> > Fix For: Jena 3.1.0
> >
> > Attachments: Screen Shot 2016-02-11 at 10.02.50.png
> >
> >
> > As discovered in TAVERNA-892 the jena-osgi of Jena 3.0.1
> > seems to have not merged correctly
> > META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> > which breaks the new Jena initialization - only TDB is initialized - but
> TDB depends on ARQ already being initialized (to get its context).
> > {code}
> > stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ unzip
> ./3.0.1/jena-osgi-3.0.1.jar
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> > Archive:  ./3.0.1/jena-osgi-3.0.1.jar
> >   inflating:
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> > stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ cat
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> > org.apache.jena.tdb.sys.In

[jira] [Commented] (JENA-1139) jena-osgi does not initialize all modules

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1139:
---

It might be easier to finally switch to bundle on the 
regular Jena packages :)

> jena-osgi does not initialize all modules
> -
>
> Key: JENA-1139
> URL: https://issues.apache.org/jira/browse/JENA-1139
> Project: Apache Jena
>  Issue Type: Bug
>  Components: OSGi
>Affects Versions: Jena 3.0.1
>    Reporter: Stian Soiland-Reyes
>
> As discovered in TAVERNA-892 the jena-osgi of Jena 3.0.1
> seems to have not merged correctly 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> which breaks the new Jena initialization - only TDB is initialized - but TDB 
> depends on ARQ already being initialized (to get its context).
> {code}
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ unzip 
> ./3.0.1/jena-osgi-3.0.1.jar 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> Archive:  ./3.0.1/jena-osgi-3.0.1.jar
>   inflating: META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle  
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ cat 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> org.apache.jena.tdb.sys.InitTDB
> {code}
> So basically only the last JenaSubsystemLifecycle file survives when  shading 
> jena-core, jena-arq, jena-tdb, jena-iri with Embed-Dependency and inline=true.
> The equivalent of the Maven Shade plugin's ServicesResourceTransformer would 
> be able to merge these.
> https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer
> but I'm not sure how this can be done with the bundle plugin.  I guess it 
> could be overridden with its own src/main/resources/META-INF/services/ file 
> in jena-osgi as well - but then it needs maintenance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1139) jena-osgi does not initialize all modules

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1139:
---

Hm, I tried that in https://github.com/stain/jena/tree/JENA-1139-transformer - 
but it gets a bit tricky as Embed-Dependency expects another Maven dependency - 
so we would then need a separate pom to make it in advance (also there's the 
trouble of both plugins being in the 'package' phase).

Would I add that as jena-singlejar/pom.xml or something under 
/apache-jena-osgi/ ? The downside is that it would also be included in the 
Maven deployment - which seems a bit overkill. (and it would not really be 
useful as a singlejar as it would not include all the required external 
dependencies that are available as OSGi).

Also somehow the 
META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle is not included 
either.

{code}
stain@biggie:~/src/jena/apache-jena-osgi$ cd -
/home/stain/src/jena/apache-jena-osgi/jena-osgi
stain@biggie:~/src/jena/apache-jena-osgi/jena-osgi$ unzip -t 
target/jena-merged.jar | grep MET | grep jena
testing: META-INF/maven/org.apache.jena/   OK
testing: META-INF/maven/org.apache.jena/jena-osgi/   OK
testing: META-INF/maven/org.apache.jena/jena-osgi/pom.properties   OK
testing: META-INF/maven/org.apache.jena/jena-osgi/pom.xml   OK
{code}

> jena-osgi does not initialize all modules
> -
>
> Key: JENA-1139
> URL: https://issues.apache.org/jira/browse/JENA-1139
> Project: Apache Jena
>  Issue Type: Bug
>  Components: OSGi
>Affects Versions: Jena 3.0.1
>Reporter: Stian Soiland-Reyes
>
> As discovered in TAVERNA-892 the jena-osgi of Jena 3.0.1
> seems to have not merged correctly 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> which breaks the new Jena initialization - only TDB is initialized - but TDB 
> depends on ARQ already being initialized (to get its context).
> {code}
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ unzip 
> ./3.0.1/jena-osgi-3.0.1.jar 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> Archive:  ./3.0.1/jena-osgi-3.0.1.jar
>   inflating: META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle  
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ cat 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> org.apache.jena.tdb.sys.InitTDB
> {code}
> So basically only the last JenaSubsystemLifecycle file survives when  shading 
> jena-core, jena-arq, jena-tdb, jena-iri with Embed-Dependency and inline=true.
> The equivalent of the Maven Shade plugin's ServicesResourceTransformer would 
> be able to merge these.
> https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer
> but I'm not sure how this can be done with the bundle plugin.  I guess it 
> could be overridden with its own src/main/resources/META-INF/services/ file 
> in jena-osgi as well - but then it needs maintenance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1139) jena-osgi does not initialize all modules

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1139:
---

Yes, I think that could also work, if the shade plugin runs first, and then 
maven-bundle-plugin can be configured to inline the shaded JAR instead. An 
additional benefit is that the LICENSE and NOTICE files are also merged.

> jena-osgi does not initialize all modules
> -
>
> Key: JENA-1139
> URL: https://issues.apache.org/jira/browse/JENA-1139
> Project: Apache Jena
>  Issue Type: Bug
>  Components: OSGi
>Affects Versions: Jena 3.0.1
>    Reporter: Stian Soiland-Reyes
>
> As discovered in TAVERNA-892 the jena-osgi of Jena 3.0.1
> seems to have not merged correctly 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> which breaks the new Jena initialization - only TDB is initialized - but TDB 
> depends on ARQ already being initialized (to get its context).
> {code}
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ unzip 
> ./3.0.1/jena-osgi-3.0.1.jar 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> Archive:  ./3.0.1/jena-osgi-3.0.1.jar
>   inflating: META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle  
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ cat 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> org.apache.jena.tdb.sys.InitTDB
> {code}
> So basically only the last JenaSubsystemLifecycle file survives when  shading 
> jena-core, jena-arq, jena-tdb, jena-iri with Embed-Dependency and inline=true.
> The equivalent of the Maven Shade plugin's ServicesResourceTransformer would 
> be able to merge these.
> https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer
> but I'm not sure how this can be done with the bundle plugin.  I guess it 
> could be overridden with its own src/main/resources/META-INF/services/ file 
> in jena-osgi as well - but then it needs maintenance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1139) jena-osgi does not initialize all modules

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1139:
---

Note, in TAVERNA-892 we recreated this even when not running inside OSGi by 
using only the jena-osgi 3.0.1 Maven dependency.

{code}
test(org.apache.taverna.robundle.validator.ValidatorTest)  Time elapsed: 0.418 
sec  <<< ERROR!
java.lang.ExceptionInInitializerError: null
at 
org.apache.jena.tdb.sys.EnvTDB.processGlobalSystemProperties(EnvTDB.java:33)
at org.apache.jena.tdb.TDB.init(TDB.java:250)
at org.apache.jena.tdb.sys.InitTDB.start(InitTDB.java:29)
at org.apache.jena.system.JenaSystem.lambda$init$40(JenaSystem.java:114)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:179)
at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:156)
at org.apache.jena.system.JenaSystem.init(JenaSystem.java:111)
at org.apache.jena.rdf.model.ModelFactory.(ModelFactory.java:49)
at 
org.apache.taverna.robundle.manifest.RDFToManifest.loadOntologyFromClasspath(RDFToManifest.java:315)
at 
org.apache.taverna.robundle.manifest.RDFToManifest.loadDCT(RDFToManifest.java:262)
at 
org.apache.taverna.robundle.manifest.RDFToManifest.loadOntologies(RDFToManifest.java:304)
at 
org.apache.taverna.robundle.manifest.RDFToManifest.(RDFToManifest.java:182)
at 
org.apache.taverna.robundle.Bundle.readOrPopulateManifest(Bundle.java:114)
at org.apache.taverna.robundle.Bundle.getManifest(Bundle.java:87)
at 
org.apache.taverna.robundle.validator.RoValidator.validate(RoValidator.java:88)
at 
org.apache.taverna.robundle.validator.RoValidator.(RoValidator.java:80)
at 
org.apache.taverna.robundle.validator.ValidatorTest.test(ValidatorTest.java:47)
{code}

> jena-osgi does not initialize all modules
> -
>
> Key: JENA-1139
> URL: https://issues.apache.org/jira/browse/JENA-1139
> Project: Apache Jena
>  Issue Type: Bug
>  Components: OSGi
>Affects Versions: Jena 3.0.1
>Reporter: Stian Soiland-Reyes
>
> As discovered in TAVERNA-892 the jena-osgi of Jena 3.0.1
> seems to have not merged correctly 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> which breaks the new Jena initialization - only TDB is initialized - but TDB 
> depends on ARQ already being initialized (to get its context).
> {code}
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ unzip 
> ./3.0.1/jena-osgi-3.0.1.jar 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> Archive:  ./3.0.1/jena-osgi-3.0.1.jar
>   inflating: META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle  
> stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ cat 
> META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
> org.apache.jena.tdb.sys.InitTDB
> {code}
> So basically only the last JenaSubsystemLifecycle file survives when  shading 
> jena-core, jena-arq, jena-tdb, jena-iri with Embed-Dependency and inline=true.
> The equivalent of the Maven Shade plugin's ServicesResourceTransformer would 
> be able to merge these.
> https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer
> but I'm not sure how this can be done with the bundle plugin.  I guess it 
> could be overridden with its own src/main/resources/META-INF/services/ file 
> in jena-osgi as well - but then it needs maintenance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1139) jena-osgi does not initialize all modules

[Stian Soiland-Reyes (JIRA)]

Stian Soiland-Reyes created JENA-1139:
-

 Summary: jena-osgi does not initialize all modules
 Key: JENA-1139
 URL: https://issues.apache.org/jira/browse/JENA-1139
 Project: Apache Jena
  Issue Type: Bug
  Components: OSGi
Affects Versions: Jena 3.0.1
Reporter: Stian Soiland-Reyes


As discovered in TAVERNA-892 the jena-osgi of Jena 3.0.1
seems to have not merged correctly 
META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle

which breaks the new Jena initialization - only TDB is initialized - but TDB 
depends on ARQ already being initialized (to get its context).

{code}
stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ unzip 
./3.0.1/jena-osgi-3.0.1.jar 
META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
Archive:  ./3.0.1/jena-osgi-3.0.1.jar
  inflating: META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle  

stain@biggie:~/.m2/repository/org/apache/jena/jena-osgi$ cat 
META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
org.apache.jena.tdb.sys.InitTDB
{code}

So basically only the last JenaSubsystemLifecycle file survives when  shading 
jena-core, jena-arq, jena-tdb, jena-iri with Embed-Dependency and inline=true.

The equivalent of the Maven Shade plugin's ServicesResourceTransformer would be 
able to merge these.

https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer

but I'm not sure how this can be done with the bundle plugin.  I guess it could 
be overridden with its own src/main/resources/META-INF/services/ file in 
jena-osgi as well - but then it needs maintenance.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (JENA-1039) Race condition on OWL.java class constructor

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes reopened JENA-1039:
---

Sorry, I'll leave the issue Open until the pull request has been accepted.

> Race condition on OWL.java class constructor
> 
>
> Key: JENA-1039
> URL: https://issues.apache.org/jira/browse/JENA-1039
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, Core
>Affects Versions: Jena 3.0.1
> Environment: stain@biggie:~/src/jena/jena-arq$ mvn -version
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 
> 2015-04-22T12:57:37+01:00)
> Maven home: /home/stain/software/maven
> Java version: 1.8.0_45-internal, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-49-generic", arch: "amd64", family: "unix"
>Reporter: Stian Soiland-Reyes
>
> latest master (fa26eefe0f55ae26cde88e7a4945bc9349a7e5f5) fails mvn clean 
> install on jena-arq:
> {code}
> [INFO] Compiling 284 source files to 
> /home/stain/src/jena/jena-arq/target/test-classes
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java
>  
> uses unchecked or unsafe operations.
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  Recompile with -Xlint:unchecked for details.
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ jena-arq ---
> [INFO] Surefire report directory: 
> /home/stain/src/jena/jena-arq/target/surefire-reports
> ---
>  T E S T S
> ---
> Running org.apache.jena.sparql.TC_Scripted
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.495 sec <<< 
> FAILURE! - in org.apache.jena.sparql.TC_Scripted
> initializationError(org.apache.jena.sparql.TC_Scripted)  Time elapsed: 0.006 
> sec  <<< ERROR!
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.jena.ontology.ProfileRegistry.(ProfileRegistry.java:43)
> at 
> org.apache.jena.ontology.OntModelSpec.(OntModelSpec.java:49)
> at 
> org.apache.jena.assembler.assemblers.OntModelAssembler.(OntModelAssembler.java:56)
> at 
> org.apache.jena.assembler.ConstAssembler.ontModel(ConstAssembler.java:59)
> at 
> org.apache.jena.assembler.ConstAssembler.general(ConstAssembler.java:147)
> at 
> org.apache.jena.sparql.core.assembler.AssemblerUtils.init(AssemblerUtils.java:59)
> at org.apache.jena.query.ARQ.init(ARQ.java:567)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at 
> org.apache.jena.system.JenaSystem.lambda$init$44(JenaSystem.java:113)
> at 
> org.apache.jena.system.JenaSystem$$Lambda$4/1415157681.accept(Unknown Source)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:178)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:155)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:110)
> at 
> org.apache.jena.rdf.model.ModelFactory.(ModelFactory.java:49)
> at org.apache.jena.vocabulary.OWL.(OWL.java:36)
> at org.apache.jena.sparql.graph.NodeConst.(NodeConst.java:45)
> at org.apache.jena.sparql.expr.NodeValue.(NodeValue.java:126)
> at org.apache.jena.sparql.TC_Scripted.(TC_Scripted.java:40)
> at org.apache.jena.sparql.TC_Scripted.suite(TC_Scripted.java:30)
> Running org.apache.jena.sparql.resultset.TS_ResultSet
> Tests run: 77, Failures: 0, Errors: 36, Skipped: 0, Time elapsed: 0.186 sec 
> <<< FAILURE! - in org.apache.jena.sparql.resultset.TS_ResultSet
> test_RS_1(org.apache.jena.sparql.resultset.TestResultSet)  Time elapsed: 0.02 
> sec  <<< ERROR!
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.jena.rdf.model.ModelFactory
> at 
> org.apache.jena.sparql.graph.GraphFactory.makeJenaDefaultModel(GraphFactory.java:72)
> at 
> org.apache.jena.sparql.resultset.XMLInputStAX.worker(XMLInputStAX.java:143)
> at 
> org.apache.jena.sparql.resultset.XMLInputStAX.(XMLInputStAX.java:10

[jira] [Commented] (JENA-1039) Race condition on OWL.java class constructor

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1039:
---

This pull request avoids the particular race condition, but I would not rule 
out that there could be other ways to trigger the same problem when calling 
JenaSystem.init() from a static {} block.


> Race condition on OWL.java class constructor
> 
>
> Key: JENA-1039
> URL: https://issues.apache.org/jira/browse/JENA-1039
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, Core
>Affects Versions: Jena 3.0.1
> Environment: stain@biggie:~/src/jena/jena-arq$ mvn -version
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 
> 2015-04-22T12:57:37+01:00)
> Maven home: /home/stain/software/maven
> Java version: 1.8.0_45-internal, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-49-generic", arch: "amd64", family: "unix"
>Reporter: Stian Soiland-Reyes
>
> latest master (fa26eefe0f55ae26cde88e7a4945bc9349a7e5f5) fails mvn clean 
> install on jena-arq:
> {code}
> [INFO] Compiling 284 source files to 
> /home/stain/src/jena/jena-arq/target/test-classes
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java
>  
> uses unchecked or unsafe operations.
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  Recompile with -Xlint:unchecked for details.
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ jena-arq ---
> [INFO] Surefire report directory: 
> /home/stain/src/jena/jena-arq/target/surefire-reports
> ---
>  T E S T S
> ---
> Running org.apache.jena.sparql.TC_Scripted
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.495 sec <<< 
> FAILURE! - in org.apache.jena.sparql.TC_Scripted
> initializationError(org.apache.jena.sparql.TC_Scripted)  Time elapsed: 0.006 
> sec  <<< ERROR!
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.jena.ontology.ProfileRegistry.(ProfileRegistry.java:43)
> at 
> org.apache.jena.ontology.OntModelSpec.(OntModelSpec.java:49)
> at 
> org.apache.jena.assembler.assemblers.OntModelAssembler.(OntModelAssembler.java:56)
> at 
> org.apache.jena.assembler.ConstAssembler.ontModel(ConstAssembler.java:59)
> at 
> org.apache.jena.assembler.ConstAssembler.general(ConstAssembler.java:147)
> at 
> org.apache.jena.sparql.core.assembler.AssemblerUtils.init(AssemblerUtils.java:59)
> at org.apache.jena.query.ARQ.init(ARQ.java:567)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at 
> org.apache.jena.system.JenaSystem.lambda$init$44(JenaSystem.java:113)
> at 
> org.apache.jena.system.JenaSystem$$Lambda$4/1415157681.accept(Unknown Source)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:178)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:155)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:110)
> at 
> org.apache.jena.rdf.model.ModelFactory.(ModelFactory.java:49)
> at org.apache.jena.vocabulary.OWL.(OWL.java:36)
> at org.apache.jena.sparql.graph.NodeConst.(NodeConst.java:45)
> at org.apache.jena.sparql.expr.NodeValue.(NodeValue.java:126)
> at org.apache.jena.sparql.TC_Scripted.(TC_Scripted.java:40)
> at org.apache.jena.sparql.TC_Scripted.suite(TC_Scripted.java:30)
> Running org.apache.jena.sparql.resultset.TS_ResultSet
> Tests run: 77, Failures: 0, Errors: 36, Skipped: 0, Time elapsed: 0.186 sec 
> <<< FAILURE! - in org.apache.jena.sparql.resultset.TS_ResultSet
> test_RS_1(org.apache.jena.sparql.resultset.TestResultSet)  Time elapsed: 0.02 
> sec  <<< ERROR!
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.jena.rdf.model.ModelFactory
> at 
> org.apache.jena.sparql.graph.GraphFactory.makeJenaDefaultModel(GraphFactory.java:72)
> at 
> org.apache.jena.sparql.resultset.XMLInputStAX

[jira] [Resolved] (JENA-1039) Race condition on OWL.java class constructor

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes resolved JENA-1039.
---
Resolution: Fixed

> Race condition on OWL.java class constructor
> 
>
> Key: JENA-1039
> URL: https://issues.apache.org/jira/browse/JENA-1039
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, Core
>Affects Versions: Jena 3.0.1
> Environment: stain@biggie:~/src/jena/jena-arq$ mvn -version
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 
> 2015-04-22T12:57:37+01:00)
> Maven home: /home/stain/software/maven
> Java version: 1.8.0_45-internal, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-49-generic", arch: "amd64", family: "unix"
>Reporter: Stian Soiland-Reyes
>
> latest master (fa26eefe0f55ae26cde88e7a4945bc9349a7e5f5) fails mvn clean 
> install on jena-arq:
> {code}
> [INFO] Compiling 284 source files to 
> /home/stain/src/jena/jena-arq/target/test-classes
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java
>  
> uses unchecked or unsafe operations.
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  Recompile with -Xlint:unchecked for details.
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ jena-arq ---
> [INFO] Surefire report directory: 
> /home/stain/src/jena/jena-arq/target/surefire-reports
> ---
>  T E S T S
> ---
> Running org.apache.jena.sparql.TC_Scripted
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.495 sec <<< 
> FAILURE! - in org.apache.jena.sparql.TC_Scripted
> initializationError(org.apache.jena.sparql.TC_Scripted)  Time elapsed: 0.006 
> sec  <<< ERROR!
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.jena.ontology.ProfileRegistry.(ProfileRegistry.java:43)
> at 
> org.apache.jena.ontology.OntModelSpec.(OntModelSpec.java:49)
> at 
> org.apache.jena.assembler.assemblers.OntModelAssembler.(OntModelAssembler.java:56)
> at 
> org.apache.jena.assembler.ConstAssembler.ontModel(ConstAssembler.java:59)
> at 
> org.apache.jena.assembler.ConstAssembler.general(ConstAssembler.java:147)
> at 
> org.apache.jena.sparql.core.assembler.AssemblerUtils.init(AssemblerUtils.java:59)
> at org.apache.jena.query.ARQ.init(ARQ.java:567)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at 
> org.apache.jena.system.JenaSystem.lambda$init$44(JenaSystem.java:113)
> at 
> org.apache.jena.system.JenaSystem$$Lambda$4/1415157681.accept(Unknown Source)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:178)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:155)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:110)
> at 
> org.apache.jena.rdf.model.ModelFactory.(ModelFactory.java:49)
> at org.apache.jena.vocabulary.OWL.(OWL.java:36)
> at org.apache.jena.sparql.graph.NodeConst.(NodeConst.java:45)
> at org.apache.jena.sparql.expr.NodeValue.(NodeValue.java:126)
> at org.apache.jena.sparql.TC_Scripted.(TC_Scripted.java:40)
> at org.apache.jena.sparql.TC_Scripted.suite(TC_Scripted.java:30)
> Running org.apache.jena.sparql.resultset.TS_ResultSet
> Tests run: 77, Failures: 0, Errors: 36, Skipped: 0, Time elapsed: 0.186 sec 
> <<< FAILURE! - in org.apache.jena.sparql.resultset.TS_ResultSet
> test_RS_1(org.apache.jena.sparql.resultset.TestResultSet)  Time elapsed: 0.02 
> sec  <<< ERROR!
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.jena.rdf.model.ModelFactory
> at 
> org.apache.jena.sparql.graph.GraphFactory.makeJenaDefaultModel(GraphFactory.java:72)
> at 
> org.apache.jena.sparql.resultset.XMLInputStAX.worker(XMLInputStAX.java:143)
> at 
> org.apache.jena.sparql.resultset.XMLInputStAX.(XMLInputStAX.java:104)
> at org.apache.jena.sparql.resultset.XMLInput.make(XMLInput.java:81)
> at org.apache.jena.sp

[jira] [Commented] (JENA-1039) Race condition on OWL.java class constructor

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1039:
---

Avoiding this inter-twingled static initialization code is why people invented 
Spring.. This is screaming for further refactoring..  :)  

So it's partially caused by InitJenaCore just calling OWL.getURI() (which the 
compiler figures out is just a String constant) rather than say 
OWL.FULL_LANG.getURI() - thus the individual constants of OWL from OWL.m_model 
has not necessarily been created yet during class initialization.

The biggest problem in that OWL requires ModelFactory, that also forces 
JenaSystem.init().  Thus both OWL and ModelFactory must participate in 
initialization.

This simple test highlights the problem - if run standalone:

{code}
package org.apache.jena.vocabulary.test;

import static org.junit.Assert.assertEquals;

import org.apache.jena.vocabulary.OWL;
import org.junit.Test;

// Deliberately not part of the test case 
public class TestOWLConstruction {

@Test
public void testName() throws Exception {
assertEquals("http://www.w3.org/2002/07/owl#sameAs";, 
OWL.sameAs.getURI());
}
}
{code}

Changing InitJenaCore to call OWL.init() does not help:

{code}
public static void init() {
System.out.println(m_model != null);
}
{code}

which prints out "false". Obviously one can make  m_model non-final and set it 
from final if null - but that does not mean that the rest of OWL.java has been 
initialized for code which first Jena thing they do is the equivalent of 
OWL.FULL_LANG.getURI().  And obviously we don't want the public constants to be 
non-final! :)

The ProfileRegistry can be changed to look up String constants instead, which 
might help as a workaround. But I'm not very convinced by cross-module class 
initialization dependencies like what has been introduced now.


> Race condition on OWL.java class constructor
> 
>
> Key: JENA-1039
> URL: https://issues.apache.org/jira/browse/JENA-1039
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, Core
>Affects Versions: Jena 3.0.1
> Environment: stain@biggie:~/src/jena/jena-arq$ mvn -version
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 
> 2015-04-22T12:57:37+01:00)
> Maven home: /home/stain/software/maven
> Java version: 1.8.0_45-internal, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-49-generic", arch: "amd64", family: "unix"
>Reporter: Stian Soiland-Reyes
>
> latest master (fa26eefe0f55ae26cde88e7a4945bc9349a7e5f5) fails mvn clean 
> install on jena-arq:
> {code}
> [INFO] Compiling 284 source files to 
> /home/stain/src/jena/jena-arq/target/test-classes
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java
>  
> uses unchecked or unsafe operations.
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  Recompile with -Xlint:unchecked for details.
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ jena-arq ---
> [INFO] Surefire report directory: 
> /home/stain/src/jena/jena-arq/target/surefire-reports
> ---
>  T E S T S
> ---
> Running org.apache.jena.sparql.TC_Scripted
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.495 sec <<< 
> FAILURE! - in org.apache.jena.sparql.TC_Scripted
> initializationError(org.apache.jena.sparql.TC_Scripted)  Time elapsed: 0.006 
> sec  <<< ERROR!
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.jena.ontology.ProfileRegistry.(ProfileRegistry.java:43)
> at 
> org.apache.jena.ontology.OntModelSpec.(OntModelSpec.java:49)
> at 
> org.apache.jena.assembler.assemblers.OntModelAssembler.(OntModelAssembler.java:56)
> at 
> org.apache.jena.assembler.ConstAssembler.ontModel(ConstAssembler.java:59)
> at 
> org.apache.jena.assembler.ConstAssembler.general(ConstAssembler.java:147)
> at 
> org.apache.jena.sparql.core.assembler.AssemblerUtils.init(AssemblerUtils.java:59)
> at org.apache.jena.query.ARQ.init(ARQ.ja

[jira] [Updated] (JENA-1039) Race condition on OWL.java class constructor

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes updated JENA-1039:
--
Component/s: Core
Summary: Race condition on OWL.java class constructor  (was: NoClassDef 
errors on jena-arq tests)

> Race condition on OWL.java class constructor
> 
>
> Key: JENA-1039
> URL: https://issues.apache.org/jira/browse/JENA-1039
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, Core
>Affects Versions: Jena 3.0.1
> Environment: stain@biggie:~/src/jena/jena-arq$ mvn -version
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 
> 2015-04-22T12:57:37+01:00)
> Maven home: /home/stain/software/maven
> Java version: 1.8.0_45-internal, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-49-generic", arch: "amd64", family: "unix"
>Reporter: Stian Soiland-Reyes
>
> latest master (fa26eefe0f55ae26cde88e7a4945bc9349a7e5f5) fails mvn clean 
> install on jena-arq:
> {code}
> [INFO] Compiling 284 source files to 
> /home/stain/src/jena/jena-arq/target/test-classes
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java
>  
> uses unchecked or unsafe operations.
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  Recompile with -Xlint:unchecked for details.
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ jena-arq ---
> [INFO] Surefire report directory: 
> /home/stain/src/jena/jena-arq/target/surefire-reports
> ---
>  T E S T S
> ---
> Running org.apache.jena.sparql.TC_Scripted
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.495 sec <<< 
> FAILURE! - in org.apache.jena.sparql.TC_Scripted
> initializationError(org.apache.jena.sparql.TC_Scripted)  Time elapsed: 0.006 
> sec  <<< ERROR!
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.jena.ontology.ProfileRegistry.(ProfileRegistry.java:43)
> at 
> org.apache.jena.ontology.OntModelSpec.(OntModelSpec.java:49)
> at 
> org.apache.jena.assembler.assemblers.OntModelAssembler.(OntModelAssembler.java:56)
> at 
> org.apache.jena.assembler.ConstAssembler.ontModel(ConstAssembler.java:59)
> at 
> org.apache.jena.assembler.ConstAssembler.general(ConstAssembler.java:147)
> at 
> org.apache.jena.sparql.core.assembler.AssemblerUtils.init(AssemblerUtils.java:59)
> at org.apache.jena.query.ARQ.init(ARQ.java:567)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at 
> org.apache.jena.system.JenaSystem.lambda$init$44(JenaSystem.java:113)
> at 
> org.apache.jena.system.JenaSystem$$Lambda$4/1415157681.accept(Unknown Source)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:178)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:155)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:110)
> at 
> org.apache.jena.rdf.model.ModelFactory.(ModelFactory.java:49)
> at org.apache.jena.vocabulary.OWL.(OWL.java:36)
> at org.apache.jena.sparql.graph.NodeConst.(NodeConst.java:45)
> at org.apache.jena.sparql.expr.NodeValue.(NodeValue.java:126)
> at org.apache.jena.sparql.TC_Scripted.(TC_Scripted.java:40)
> at org.apache.jena.sparql.TC_Scripted.suite(TC_Scripted.java:30)
> Running org.apache.jena.sparql.resultset.TS_ResultSet
> Tests run: 77, Failures: 0, Errors: 36, Skipped: 0, Time elapsed: 0.186 sec 
> <<< FAILURE! - in org.apache.jena.sparql.resultset.TS_ResultSet
> test_RS_1(org.apache.jena.sparql.resultset.TestResultSet)  Time elapsed: 0.02 
> sec  <<< ERROR!
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.jena.rdf.model.ModelFactory
> at 
> org.apache.jena.sparql.graph.GraphFactory.makeJenaDefaultModel(GraphFactory.java:72)
> at 
> org.apache.jena.sparql.resultset.XMLInputStAX.worker(XMLInputStAX.java:143)
> at 
> org.apache.jena.sparql.resultset.XMLInputStAX.(XMLInputStAX.java:104)
&g

[jira] [Commented] (JENA-1039) NoClassDef errors on jena-arq tests

[Stian Soiland-Reyes (JIRA)]

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

Stian Soiland-Reyes commented on JENA-1039:
---

Some kind of race condition.. ProfileRegistry does

{code}
/** The URI that maps to the language profile for OWL-Full */
public static final String OWL_LANG = OWL.FULL_LANG.getURI();
{code}

but FULL_LANG on line 49 in OWL.java is:

{code}
public static final Resource FULL_LANG = m_model.getResource( getURI() );
{code}

but we are already part of OWL's class constructor on line 36, 

{code}
private static final Model m_model = ModelFactory.createDefaultModel();
{code}

> NoClassDef errors on jena-arq tests
> ---
>
> Key: JENA-1039
> URL: https://issues.apache.org/jira/browse/JENA-1039
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.0.1
> Environment: stain@biggie:~/src/jena/jena-arq$ mvn -version
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 
> 2015-04-22T12:57:37+01:00)
> Maven home: /home/stain/software/maven
> Java version: 1.8.0_45-internal, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-49-generic", arch: "amd64", family: "unix"
>Reporter: Stian Soiland-Reyes
>
> latest master (fa26eefe0f55ae26cde88e7a4945bc9349a7e5f5) fails mvn clean 
> install on jena-arq:
> {code}
> [INFO] Compiling 284 source files to 
> /home/stain/src/jena/jena-arq/target/test-classes
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java
>  
> uses unchecked or unsafe operations.
> [WARNING] 
> /home/stain/src/jena/jena-arq/src/test/java/org/apache/jena/sparql/graph/TestGraphUnionRead.java:
>  Recompile with -Xlint:unchecked for details.
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ jena-arq ---
> [INFO] Surefire report directory: 
> /home/stain/src/jena/jena-arq/target/surefire-reports
> ---
>  T E S T S
> ---
> Running org.apache.jena.sparql.TC_Scripted
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.495 sec <<< 
> FAILURE! - in org.apache.jena.sparql.TC_Scripted
> initializationError(org.apache.jena.sparql.TC_Scripted)  Time elapsed: 0.006 
> sec  <<< ERROR!
> java.lang.ExceptionInInitializerError: null
> at 
> org.apache.jena.ontology.ProfileRegistry.(ProfileRegistry.java:43)
> at 
> org.apache.jena.ontology.OntModelSpec.(OntModelSpec.java:49)
> at 
> org.apache.jena.assembler.assemblers.OntModelAssembler.(OntModelAssembler.java:56)
> at 
> org.apache.jena.assembler.ConstAssembler.ontModel(ConstAssembler.java:59)
> at 
> org.apache.jena.assembler.ConstAssembler.general(ConstAssembler.java:147)
> at 
> org.apache.jena.sparql.core.assembler.AssemblerUtils.init(AssemblerUtils.java:59)
> at org.apache.jena.query.ARQ.init(ARQ.java:567)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at 
> org.apache.jena.system.JenaSystem.lambda$init$44(JenaSystem.java:113)
> at 
> org.apache.jena.system.JenaSystem$$Lambda$4/1415157681.accept(Unknown Source)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:178)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:155)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:110)
> at 
> org.apache.jena.rdf.model.ModelFactory.(ModelFactory.java:49)
> at org.apache.jena.vocabulary.OWL.(OWL.java:36)
> at org.apache.jena.sparql.graph.NodeConst.(NodeConst.java:45)
> at org.apache.jena.sparql.expr.NodeValue.(NodeValue.java:126)
> at org.apache.jena.sparql.TC_Scripted.(TC_Scripted.java:40)
> at org.apache.jena.sparql.TC_Scripted.suite(TC_Scripted.java:30)
> Running org.apache.jena.sparql.resultset.TS_ResultSet
> Tests run: 77, Failures: 0, Errors: 36, Skipped: 0, Time elapsed: 0.186 sec 
> <<< FAILURE! - in org.apache.jena.sparql.resultset.TS_ResultSet
> test_RS_1(org.apache.jena.sparql.resultset.TestResultSet)  Time elapsed: 0.02 
> sec  <