date:20160107

Re: Safe update and select queries against Fuseki with user input

2016-01-07 Thread Andy Seaborne


Hi Håvard,

That's not what should happen!

Could you turn that into a complete, minimal example and create a JIRA 
please?


Andy

On 07/01/16 09:09, Håvard Mikkelsen Ottestad wrote:

Hi Andy,

I tried the QueryBuilder, but it doesn’t work for update queries.

The UpdateTransformOps looks good, however it seems to be removing a filter 
from my query. The filter is used to stop stop duplicate usernames.

##
### BEFORE ###
##


PREFIX foaf: 
PREFIX : 

INSERT {
GRAPH  {
 
foaf:accountName ?username .
 
:role ?role .
 
:password ?password .
 
 :User .
}
}
WHERE{
FILTER ( ! EXISTS { ?a foaf:accountName ?username } )  THIS FILTER 
GETS REMOVED WHEN I TRANSFORM
}




#
### AFTER ###
#

PREFIX foaf: 
PREFIX : 

INSERT {
GRAPH  {
 
foaf:accountName "testUserName" .
 :role 
"" .
 :password 
"" .
 
 :User .
}
}
WHERE
{}  THE FILTER HERE IS MISSING !!!




Håvard




On 06/01/16 20:18, "Andy Seaborne"  wrote:


Is it possible to do something similar when running these queries against 
Fuseki over HTTP?


Håvard,

What is the starting point? A string as the template or an
already-parsed query or update? Or building the  structure each time?

1:: If it is a string,  parameterized sparql strings are the way to go
and it protects against injected strings for

2:: There is also the QueryBuilder
https://jena.apache.org/documentation/extras/querybuilder/
that Claude can talk about.

Last time we had a discussion about this
http://mail-archives.apache.org/mod_mbox/jena-dev/201506.mbox/%3C558FC784.9060407%40apache.org%3E

3:: I put in the machinery for syntax rewriting: it does not have a
QuerySolution based interface:

UpdateTransformOps / QueryTransformOps

It would be good to know the details here of your use case: do you only
want to inject values for specific parameters, not partial patterns?

It would help use further understand the different alternatives and
workflows.

Andy

What to use instead SimpleBulkUpdateHandler on jena 3?

2016-01-07 Thread Marco Tenti

Hi, very simple question, i must update a old project from jena 2 to jena
3, what it's the best otion to replace all the "BulkUpdateHandler"
extensions to use the new Graph package in jena 3?

Re: Safe update and select queries against Fuseki with user input

2016-01-07 Thread Håvard Mikkelsen Ottestad

https://issues.apache.org/jira/browse/JENA-1112


I put it as critical, but I’m using the parameterized sparql strings for the 
time being. So it’s not really critical for me.

Håvard




On 07/01/16 13:27, "Andy Seaborne"  wrote:

>Hi Håvard,
>
>That's not what should happen!
>
>Could you turn that into a complete, minimal example and create a JIRA 
>please?
>
>   Andy
>
>On 07/01/16 09:09, Håvard Mikkelsen Ottestad wrote:
>> Hi Andy,
>>
>> I tried the QueryBuilder, but it doesn’t work for update queries.
>>
>> The UpdateTransformOps looks good, however it seems to be removing a filter 
>> from my query. The filter is used to stop stop duplicate usernames.
>>
>> ##
>> ### BEFORE ###
>> ##
>>
>>
>> PREFIX foaf: 
>> PREFIX : 
>>
>> INSERT {
>>  GRAPH  {
>>   
>> foaf:accountName ?username .
>>   
>> :role ?role .
>>   
>> :password ?password .
>>   
>>  :User .
>>  }
>> }
>> WHERE{
>>  FILTER ( ! EXISTS { ?a foaf:accountName ?username } )  THIS FILTER 
>> GETS REMOVED WHEN I TRANSFORM
>> }
>>
>>
>>
>>
>> #
>> ### AFTER ###
>> #
>>
>> PREFIX foaf: 
>> PREFIX : 
>>
>> INSERT {
>>  GRAPH  {
>>   
>> foaf:accountName "testUserName" .
>>   
>> :role "" .
>>   
>> :password "" .
>>   
>>  :User .
>>  }
>> }
>> WHERE
>> {}  THE FILTER HERE IS MISSING !!!
>>
>>
>>
>>
>> Håvard
>>
>>
>>
>>
>> On 06/01/16 20:18, "Andy Seaborne"  wrote:
>>
 Is it possible to do something similar when running these queries against 
 Fuseki over HTTP?
>>>
>>> Håvard,
>>>
>>> What is the starting point? A string as the template or an
>>> already-parsed query or update? Or building the  structure each time?
>>>
>>> 1:: If it is a string,  parameterized sparql strings are the way to go
>>> and it protects against injected strings for
>>>
>>> 2:: There is also the QueryBuilder
>>> https://jena.apache.org/documentation/extras/querybuilder/
>>> that Claude can talk about.
>>>
>>> Last time we had a discussion about this
>>> http://mail-archives.apache.org/mod_mbox/jena-dev/201506.mbox/%3C558FC784.9060407%40apache.org%3E
>>>
>>> 3:: I put in the machinery for syntax rewriting: it does not have a
>>> QuerySolution based interface:
>>>
>>> UpdateTransformOps / QueryTransformOps
>>>
>>> It would be good to know the details here of your use case: do you only
>>> want to inject values for specific parameters, not partial patterns?
>>>
>>> It would help use further understand the different alternatives and
>>> workflows.
>>>
>>> Andy
>>>
>

Re: optimizing serialization of results from fuseki

2016-01-07 Thread Paul Tyson

On Thu, 2016-01-07 at 08:48 +, Håvard Mikkelsen Ottestad wrote:
> Hi,
> 
> Reordering the filters might help.
I've tried a bit of this, without much noticeable effect. I understand
that these are pretty well optimized when the sparql text is converted
to algebra.

> 
> Also, maybe a stats file would reorder your query to be faster. I dunno how 
> often (or if) fuseki generates a stats file. You can try to generate one by 
> hand when fuseki is shutdown: 
> https://jena.apache.org/documentation/tdb/optimizer.html
> 
There is a stats.opt file so I assume it's using that for optimization.

> Also I’m wondering what the performance is like if you take this line away: 
> ?s :p1/:p2 ?nd.
> 
When this occurs last in the BGP it does not have much effect. At the
top of the BGP it really slowed things down.

> 
> One major performance drain I have seen in the past is filters on string 
> literals. Especially if you are doing anything like CONTAINS or LOWERCASE. Do 
> you have any of that?
> 
I think all my filters are on numeric literals or URIs (see sample query
in other post). On other projects I also have noticed the impact of
string filters, and got much better results using Lucene add-on for
that.

Regards,
--Paul

> Håvard
> 
> 
> 
> 
> On 07/01/16 03:51, "Paul Tyson"  wrote:
> 
> >On Wed, 2016-01-06 at 18:52 +, Andy Seaborne wrote:
> >> Hi Paul,
> >> 
> >>  > My question is: is total query time limited by search execution speed,
> >>  > or by marshaling and serialization of search results?
> >> 
> >> Costs are a bit of both but normally mainly query.  It also depends on 
> >> the client processing.
> >> 
> >> Some context please:
> >> 1/ What's the storage layer?
> >TDB behind fuseki 2.3.1
> >
> >> 2/ What result set format are you getting?
> >text/csv
> >
> >> 3/ How are you handling the results on receipt in the client?
> >Just writing them to file for testing.
> >
> >> 
> >> (Håvard point about seeing data and query also applies)
> >Sorry, not easy to share the data.
> >
> >> 
> >> The important point is that output is streamed.
> >> 
> >> Result sent while the query is execution; it is not the case that the 
> >> query executes,. all the results calculated and then results are produced.
> >> 
> >> To investigate, modify the query to do something like this
> >> 
> >> SELECT (count(*) AS ?C) { ... }
> >> 
> >> because then the result set cost is low and all the query is executed 
> >> before a result can be produced.
> >> 
> >Yes, I did that, and the time is very nearly the same.
> >
> >So I conclude we are seeing the best performance possible unless there
> >is something terribly wrong with my queries. They are essentially of the
> >form:
> >
> >select ?s
> >where {
> >?nd :prop1 ;
> >  :prop2 "lit1";
> >  :prop3 ?var1;
> >  :prop4 ?var2;
> ># more properties of ?s
> >filter (?var1 > N1 && ?var1 < N2)
> >filter (?var2 in (,,...))
> >#more filters on ?nd properties
> >?s :p1/:p2 ?nd.
> >}
> >
> >Some of the filters get a little more complicated. And there is at least
> >one, possibly 2, UNION clauses. No OPTIONAL clauses. I've dissected the
> >queries and run each individual piece (triple + filter), and it seems to
> >be the more complicated filters that start to slow things down, as might
> >be expected.
> >
> >Thanks for your comments and interest. The performance we're seeing is
> >unacceptable for our application requirements, so I wanted to see if
> >there were any other performance factors I had missed.
> >
> >Regards,
> >--Paul
> >
> >> Andy
> >> 
> >> 
> >> On 06/01/16 16:17, Paul Tyson wrote:
> >> > I have a modest (17M triple) dataset, fairly flat graph. I run some
> >> > queries selecting nodes with anywhere from 12-20 different property
> >> > values.
> >> >
> >> > Result set counts are anywhere from 10,000 to 30,000 nodes. Total
> >> > execution time measured at client are in the 30-40 second range.
> >> >
> >> > The web request begins streaming results immediately, but seems to take
> >> > longer than it should (based on the number of results and size of data
> >> > transfer). I also notice that the time is roughly linear with the size
> >> > of dataset--halving the dataset size halves the result set and the
> >> > execution time. I wouldn't have expected this behavior if all the time
> >> > was due to an indexed search.
> >> >
> >> > My question is: is total query time limited by search execution speed,
> >> > or by marshaling and serialization of search results?
> >> >
> >> > I have tried different query patterns, and believe I have the best
> >> > queries possible for the use case.
> >> >
> >> > I'm looking for other suggestions to reduce overall execution time. The
> >> > performance does not improve drastically going from 4Gb to 8 or 16Gb
> >> > RAM. My test platforms are 64-bit Windows, ranging from small server
> >> > (16Gb RAM, 4 CPU) to laptops with 4Gb RAM.
> >> >
> >> > Thanks,
> >> > --Paul
> >> >
> >> 
> >
> >

Re: optimizing serialization of results from fuseki

2016-01-07 Thread Rob Vesse

Thoughts inline:

On 07/01/2016 15:56, "Paul Tyson"  wrote:

>Here is an actual query, partially obfuscated. It returns about 18K
>nodes in 40 seconds, from a dataset of about 17M triples. (The nodes are
>not necessarily distinct.)
>
>The predominant graph structure is like:
>
>?node <- ?lsu -> ?detail -> LSUPROPERTYVALUE
>
>Thanks for your attention and any suggestions for improvement.
>
>prefix rdfs: 
>prefix xsd: 
>prefix lsu: 
>prefix rdf: 
>SELECT (count(?node) as ?cnt)
>WHERE {
>?detail lsu:source "XYZ".
>?detail lsu:length-type "Ltype".
>?detail lsu:max-length-exclusive ?maxe_len;
>  lsu:max-length-inclusive ?maxi_len;
>  lsu:min-length-inclusive ?mine_len;
>  lsu:min-length-exclusive ?mini_len.
>FILTER (
>  (?maxe_len = rdf:nil || ?maxe_len > "95"^^xsd:decimal)
>  && (?maxi_len = rdf:nil || ?maxi_len >= "95"^^xsd:decimal)
>  && (?mine_len = rdf:nil || ?mine_len < "95"^^xsd:decimal)
>  && (?mini_len  = rdf:nil || ?mini_len <= "95"^^xsd:decimal)
>)

It looks like you create triples of the form   rdf:nil
to indicate non-existent values.  Typically people would simply omit those
triple(s) and infer the non-existent value by lack of matching (using
OPTIONAL/EXISTS/NOT EXISTS as desired).  This would probably be a
significant change to your data model so perhaps not an option for you but
worth mentioning.

If you were willing to make this change then you'd need to use OPTIONAL
for things that might not have values present which has other performance
costs associated with it.  However if you did make this change then TDB
can potentially push the numeric filter condition down into its index scan
which would likely outweigh any negative performance impact of using
OPTIONAL.  As it stands because all the conditions are logical or
conditions they can't be pushed down directly into TDB index scans AFAIK
(Andy - please correct me if I'm wrong)

One possible experiment to try that doesn't require changing the data
model would be to drop all the ?var = rdf:nil clauses from your various
FILTER expressions and see what effect on performance that has.

>?detail lsu:date-type "Date type 1".
>{{
>  ?detail lsu:retroactive true;
>lsu:end-date rdf:nil .
>} UNION {
>  ?detail lsu:retroactive false;
>lsu:start-date ?start ;
>lsu:end-date ?end .
>  FILTER (?start <= "2006-08-11"^^xsd:date
>  && (?end = rdf:nil || ?end >= "2006-08-11"^^xsd:date))
>}}
>?detail lsu:minimum-age ?min_age;
>  lsu:maximum-age ?max_age.
>FILTER ((?max_age = rdf:nil || ?max_age >= 8)
> && (?min_age = 0 || ?min_age < 8))
>?detail lsu:applicable-for "adfsda" .
>?detail lsu:v-type ?v_type.
>FILTER (?v_type in (rdf:nil, ))

Using the IN syntax can be quite expensive because a store has to
potentially pick out a large set of potential matches and then filter, for
a small number of values using a UNION with one of the constants
substituted into each branch may offer better performance though not sure
how much it will help here.  Note that Jena performs this optimization
anyway so probably makes little difference to your query

>?detail lsu:s-type ?s_type.
>FILTER (?s_type in (rdf:nil, ))
>?detail lsu:max-gg-exclusive ?maxe_gg;
>  lsu:max-gg-inclusive ?maxi_gg;
>  lsu:min-gg-inclusive ?mine_gg;
>  lsu:min-gg-exclusive ?mini_gg.
>FILTER (
>  (?maxe_gg = rdf:nil || ?maxe_gg > "50"^^xsd:decimal)
>  && (?maxi_gg = rdf:nil || ?maxi_gg >= "50"^^xsd:decimal)
>  && (?mine_gg = rdf:nil || ?mine_gg < "50"^^xsd:decimal)
>  && (?mini_gg = rdf:nil || ?mini_gg <= "50"^^xsd:decimal)
>)

Again same point about use of rdf:nil

>?detail lsu:h-m ?h_m.
>FILTER (?h_m in (rdf:nil, ))
>{{
>?detail lsu:v-func ?v_func.
>FILTER (?v_func in
>(,))
>} UNION {
>?detail lsu:c-n ?c_n.
>FILTER (?c_n in
>(,,<
>http://www.example.org/2015/7/cn3>,))
>}}
>?lsu lsu:lsu-d ?detail.
>?lsu lsu:aF ?node.
>}

In general I'm not sure I see huge room for improvement without knowing
more about the statistics of the data.  If a later part of the query is
likely to match a smaller subset of the data than an earlier part then you
can try moving the pieces of the query around.  You have a lot of value
based filters which tend to be hard to optimised in general and as noted
their use as arguments to || expressions probably blocks TDB from pushing
those down directly into the index scans.

The algebra for the query looks reasonable other than being large because
the query is large, all the FILTER expressions look like they get pushed
down and evaluated as soon as reasonably possible.

Rob

>
>
>On Thu, 2016-01-07 at 12:36 +, Andy Seaborne

Re: What to use instead SimpleBulkUpdateHandler on jena 3?

2016-01-07 Thread Andy Seaborne


On 07/01/16 15:11, Marco Tenti wrote:

Hi, very simple question, i must update a old project from jena 2 to jena
3, what it's the best otion to replace all the "BulkUpdateHandler"
extensions to use the new Graph package in jena 3?



org.apache.jena.graph.GraphUtil has functions add() and delete() to 
replace the BulkUpdateHandler operations.


Andy

Re: optimizing serialization of results from fuseki

2016-01-07 Thread Paul Tyson

Here is an actual query, partially obfuscated. It returns about 18K
nodes in 40 seconds, from a dataset of about 17M triples. (The nodes are
not necessarily distinct.)

The predominant graph structure is like:

?node <- ?lsu -> ?detail -> LSUPROPERTYVALUE

Thanks for your attention and any suggestions for improvement.

prefix rdfs: 
prefix xsd: 
prefix lsu: 
prefix rdf: 
SELECT (count(?node) as ?cnt)
WHERE {
?detail lsu:source "XYZ".
?detail lsu:length-type "Ltype".
?detail lsu:max-length-exclusive ?maxe_len;
  lsu:max-length-inclusive ?maxi_len;
  lsu:min-length-inclusive ?mine_len;
  lsu:min-length-exclusive ?mini_len.
FILTER (
  (?maxe_len = rdf:nil || ?maxe_len > "95"^^xsd:decimal)
  && (?maxi_len = rdf:nil || ?maxi_len >= "95"^^xsd:decimal)
  && (?mine_len = rdf:nil || ?mine_len < "95"^^xsd:decimal)
  && (?mini_len  = rdf:nil || ?mini_len <= "95"^^xsd:decimal)
)
?detail lsu:date-type "Date type 1".
{{
  ?detail lsu:retroactive true;
lsu:end-date rdf:nil .
} UNION {
  ?detail lsu:retroactive false;
lsu:start-date ?start ;
lsu:end-date ?end .
  FILTER (?start <= "2006-08-11"^^xsd:date
  && (?end = rdf:nil || ?end >= "2006-08-11"^^xsd:date))
}}
?detail lsu:minimum-age ?min_age;
  lsu:maximum-age ?max_age.
FILTER ((?max_age = rdf:nil || ?max_age >= 8)
 && (?min_age = 0 || ?min_age < 8))
?detail lsu:applicable-for "adfsda" .
?detail lsu:v-type ?v_type.
FILTER (?v_type in (rdf:nil, ))
?detail lsu:s-type ?s_type.
FILTER (?s_type in (rdf:nil, ))
?detail lsu:max-gg-exclusive ?maxe_gg;
  lsu:max-gg-inclusive ?maxi_gg;
  lsu:min-gg-inclusive ?mine_gg;
  lsu:min-gg-exclusive ?mini_gg.
FILTER (
  (?maxe_gg = rdf:nil || ?maxe_gg > "50"^^xsd:decimal)
  && (?maxi_gg = rdf:nil || ?maxi_gg >= "50"^^xsd:decimal)
  && (?mine_gg = rdf:nil || ?mine_gg < "50"^^xsd:decimal)
  && (?mini_gg = rdf:nil || ?mini_gg <= "50"^^xsd:decimal)
)
?detail lsu:h-m ?h_m.
FILTER (?h_m in (rdf:nil, ))
{{
?detail lsu:v-func ?v_func.
FILTER (?v_func in
(,))
} UNION {
?detail lsu:c-n ?c_n.
FILTER (?c_n in
(,,,))
}}
?lsu lsu:lsu-d ?detail.
?lsu lsu:aF ?node.
}


On Thu, 2016-01-07 at 12:36 +, Andy Seaborne wrote:
> It looks like it is the query cost and not the
> 
> > So I conclude we are seeing the best performance possible unless there
> > is something terribly wrong with my queries. They are essentially of the
> > form:
> >
> 
> Details matter here - can you show a real query?
> 
> > select ?s
> > where {
> > ?nd :prop1 ;
> >   :prop2 "lit1";
> >   :prop3 ?var1;
> >   :prop4 ?var2;
> > # more properties of ?s
> 
> ?s doesn't appear until later.
> 
> There is a chance there are cross products in the real query.
> 
> > filter (?var1 > N1 && ?var1 < N2)
> > filter (?var2 in (,,...))
> 
> This usually gets optimized - maybe something else in your query is 
> blocking that.
> 
> Filter order can matter as well.
> 
> > #more filters on ?nd properties
> > ?s :p1/:p2 ?nd.
> > }
> >
> > Some of the filters get a little more complicated. And there is at least
> > one, possibly 2, UNION clauses. No OPTIONAL clauses. I've dissected the
> > queries and run each individual piece (triple + filter), and it seems to
> > be the more complicated filters that start to slow things down, as might
> > be expected.
> >
> > Thanks for your comments and interest. The performance we're seeing is
> > unacceptable for our application requirements, so I wanted to see if
> > there were any other performance factors I had missed.
> 
>   Andy
> 
> On 07/01/16 08:48, Håvard Mikkelsen Ottestad wrote:
> > Hi,
> >
> > Reordering the filters might help.
> >
> > Also, maybe a stats file would reorder your query to be faster. I dunno how 
> > often (or if) fuseki generates a stats file. You can try to generate one by 
> > hand when fuseki is shutdown: 
> > https://jena.apache.org/documentation/tdb/optimizer.html
> >
> > Also I’m wondering what the performance is like if you take this line away:
> > ?s :p1/:p2 ?nd.
> >
> >
> > One major performance drain I have seen in the past is filters on string 
> > literals. Especially if you are doing anything like CONTAINS or LOWERCASE. 
> > Do you have any of that?
> >
> > Håvard
> >
> >
> >
> >
> > On 07/01/16 03:51, "Paul Tyson"  wrote:
> >
> >> On Wed, 2016-01-06 at 18:52 +, Andy Seaborne wrote:
> >>> Hi Paul,
> >>>
> >>>   > My question is: is total query time limited by search execution speed,
> >>>   > or by marshaling and serialization of search results?
> >>>
> >>> Costs are a bit of both but normally mainly query.  It also

Re: jena-osgi bundle dependencies

2016-01-07 Thread A. Soroka

Karaf (the OSGi container underlying ServiceMix) is able to resolve transitive 
dependencies using its “features” system[1], but that kind of resolution is not 
an inherent ability of OSGi frameworks, it’s specific to Karaf. The OSGi 
metadata in the Jena bundle just explains what other dependencies exist, not 
where or how to resolve them. It’s the Maven metadata that explains that, and 
it’s the fact that Karaf’s “features” system can take advantage of both OSGi 
metadata and Maven metadata that allows it to solve this kind of problem.

However, you can manually install bundles for those other dependencies (and 
Jena’s Maven metadata should give you some good information about what they 
are). You can also use a Karaf feature file to try to do that automatically. 
Apache Clerezza has done some of that work so you may want to check with them 
to see what they have available, e.g. [2].


[1] https://karaf.apache.org/manual/latest/users-guide/provisioning.html
[2] https://github.com/apache/clerezza/blob/master/provisioning/rdf/pom.xml

---
A. Soroka
The University of Virginia Library

> On Jan 7, 2016, at 1:46 PM, Robson, Alan  wrote:
> 
> Hi all,
> 
> I'm trying to use jena in servicemix (an apache OSGI-based system) by using 
> the jena-osgi bundle...
> 
> I can - apparently, install the pre-made bundle from maven...
> 
> karaf@root()> bundle:install mvn:org.apache.jena/jena-osgi/3.0.1
> Bundle ID: 238
> 
> I can install one of my own bundles (actually one that I adapted from 
> http://kevinboone.net/osgitest.html) to satisfy a dependency I have
> 
> karaf@root()> feature:install examples-vbb-tick
> Tick bundle started
> 
> I can then install my new custom feature.
> 
> karaf@root()> feature:install examples-vbb-zooby
> 
> 
> This all worked until I added code in the zooby bundle to access Jena - I 
> copied in some code snipped from 
> https://github.com/castagna/jena-examples/blob/master/src/main/java/org/apache/jena/examples/ExampleAPI_02.java
> 
> All of a sudden, since I added the jena code and started using the OSGI jena 
> bundle I have lots of unresolved dependencies... I believe that all bar one 
> of these is a dependency of the jena-osgi  bundle I downloaded.
> 
> Is anyone else seeing these dependency problems ? How did you fix them ?...
> 
> Error executing command: Can't install feature examples-vbb-zooby/0.0.0:
> Can not resolve feature:
> Unsatisfied requirement(s):
> ---
>   
> package:(&(package=org.apache.http.client.methods)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.http.protocol)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   package:(&(package=org.apache.http.entity))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.http.impl.client)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   package:(&(package=org.apache.http.util)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   package:(&(package=org.apache.http.conn)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.http.message)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.thrift.protocol)(version>=0.9.0)(!(version>=1.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.thrift.meta_data)(version>=0.9.0)(!(version>=1.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.http.conn.scheme)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   package:(&(package=org.apache.http))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=com.github.jsonldjava.utils)(version>=0.7.0)(!(version>=1.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.http.params)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.commons.lang3.time)(version>=3.3.0)(!(version>=4.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.http.client.utils)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.commons.cli)(version>=1.3.0)(!(version>=2.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.thrift.scheme)(version>=0.9.0)(!(version>=1.0.0)))
>  Apache Jena - OSGi bundle
>   package:(&(package=org.apache.http.auth)(version>=4.2.0)(!(version>=5.0.0)))
>  Apache Jena - OSGi bundle
>   package:(&(package=org.apache.thrift)(version>=0.9.0)(!(version>=1.0.0)))
>  Apache Jena - OSGi bundle
>   package:(&(package=com.github.andrewoma.dexx.collection))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.thrift.transport)(version>=0.9.0)(!(version>=1.0.0)))
>  Apache Jena - OSGi bundle
>   
> package:(&(package=org.apache.http.client)(version>=4.2.0)(!(version>=5.0.0)))
>

jena-osgi bundle dependencies

2016-01-07 Thread Robson, Alan

Hi all,

I'm trying to use jena in servicemix (an apache OSGI-based system) by using the 
jena-osgi bundle...

I can - apparently, install the pre-made bundle from maven...

karaf@root()> bundle:install mvn:org.apache.jena/jena-osgi/3.0.1
Bundle ID: 238

I can install one of my own bundles (actually one that I adapted from 
http://kevinboone.net/osgitest.html) to satisfy a dependency I have

karaf@root()> feature:install examples-vbb-tick
Tick bundle started

I can then install my new custom feature.

karaf@root()> feature:install examples-vbb-zooby


This all worked until I added code in the zooby bundle to access Jena - I 
copied in some code snipped from 
https://github.com/castagna/jena-examples/blob/master/src/main/java/org/apache/jena/examples/ExampleAPI_02.java

All of a sudden, since I added the jena code and started using the OSGI jena 
bundle I have lots of unresolved dependencies... I believe that all bar one of 
these is a dependency of the jena-osgi  bundle I downloaded.

Is anyone else seeing these dependency problems ? How did you fix them ?...

Error executing command: Can't install feature examples-vbb-zooby/0.0.0:
Can not resolve feature:
Unsatisfied requirement(s):
---
   
package:(&(package=org.apache.http.client.methods)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.protocol)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   package:(&(package=org.apache.http.entity))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.impl.client)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   package:(&(package=org.apache.http.util)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   package:(&(package=org.apache.http.conn)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.message)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.thrift.protocol)(version>=0.9.0)(!(version>=1.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.thrift.meta_data)(version>=0.9.0)(!(version>=1.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.conn.scheme)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   package:(&(package=org.apache.http))
  Apache Jena - OSGi bundle
   
package:(&(package=com.github.jsonldjava.utils)(version>=0.7.0)(!(version>=1.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.params)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.commons.lang3.time)(version>=3.3.0)(!(version>=4.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.client.utils)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.commons.cli)(version>=1.3.0)(!(version>=2.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.thrift.scheme)(version>=0.9.0)(!(version>=1.0.0)))
  Apache Jena - OSGi bundle
   package:(&(package=org.apache.http.auth)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   package:(&(package=org.apache.thrift)(version>=0.9.0)(!(version>=1.0.0)))
  Apache Jena - OSGi bundle
   package:(&(package=com.github.andrewoma.dexx.collection))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.thrift.transport)(version>=0.9.0)(!(version>=1.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.client)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.client.entity)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.impl.auth)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.jena.rdf.model)(version>=3.0.0)(!(version>=4.0.0)))
  Apache ServiceMix :: Examples :: VBB :: Zooby
   
package:(&(package=org.apache.commons.csv)(version>=1.0.0)(!(version>=2.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=org.apache.http.impl.conn)(version>=4.2.0)(!(version>=5.0.0)))
  Apache Jena - OSGi bundle
   
package:(&(package=com.github.jsonldjava.core)(version>=0.7.0)(!(version>=1.0.0)))
  Apache Jena - OSGi bundle

Many thanks

Alan

Re: Safe update and select queries against Fuseki with user input

What to use instead SimpleBulkUpdateHandler on jena 3?

Re: Safe update and select queries against Fuseki with user input

Re: optimizing serialization of results from fuseki

Re: optimizing serialization of results from fuseki

Re: What to use instead SimpleBulkUpdateHandler on jena 3?

Re: optimizing serialization of results from fuseki

Re: jena-osgi bundle dependencies

jena-osgi bundle dependencies

9 matches

Site Navigation

Mail list logo

Footer information