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

Andy Seaborne commented on JENA-435:
------------------------------------

Now fixed in SVN.

It was finding the shortest match not the longest.

This only applies to Graph Store Protocol requests where matching is made 
complicated by supporting indirect naming (?graph=, ?default) and also direct 
form (http://host/data/set/graph/name).
                
> Two services in one fuseki instance can conflict if the initial characters of 
> the fuseki:name of one service are equal to the full fuseki:name of the other 
> service
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JENA-435
>                 URL: https://issues.apache.org/jira/browse/JENA-435
>             Project: Apache Jena
>          Issue Type: Bug
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.6
>         Environment: tested on Mac OSX 10.8.2.
>            Reporter: Bill Roberts
>
> Steps to reproduce
> fuseki-server --config=test.ttl
> where test.ttl contains the following:
> ===============
> [] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
> tdb:DatasetTDB  rdfs:subClassOf  ja:RDFDataset .
> tdb:GraphTDB    rdfs:subClassOf  ja:Model .
> <#service1>  rdf:type fuseki:Service ;
>     fuseki:name              "abc" ;       # http://host:port/blah
>     fuseki:serviceQuery      "sparql" ;    # SPARQL query service
>     fuseki:serviceUpdate     "update" ;   # SPARQL update service
>     fuseki:serviceReadWriteGraphStore "data" ;     # SPARQL Graph store 
> protocol (read and write)
>     fuseki:dataset           <#dataset-foo> ;
>     .
> <#service2>  rdf:type fuseki:Service ;
>     fuseki:name              "abc123" ;       # http://host:port/blah
>     fuseki:serviceQuery      "sparql" ;    # SPARQL query service
>     fuseki:serviceUpdate     "update" ;   # SPARQL update service
>     fuseki:serviceReadWriteGraphStore "data" ;     # SPARQL Graph store 
> protocol (read and write)
>     fuseki:dataset           <#dataset-bar> ;
>     .    
>     
>  <#dataset-foo> rdf:type      tdb:DatasetTDB ;
>      tdb:location "/Users/bill/Data/tdb/pqr" ;
>      tdb:unionDefaultGraph true ;
>      .
> <#dataset-bar> rdf:type      tdb:DatasetTDB ;
>      tdb:location "/Users/bill/Data/tdb/xyz" ;
>      tdb:unionDefaultGraph true ;
>      .
> ============
> Create empty directories 'pqr' and 'xyz' to hold the data for the two SPARQL 
> datasets.
> Then, PUT some data into the first service (fuseki:name 'abc')  (any valid 
> RDF will do)
> curl -v -H "Content-type: text/turtle" --upload-file file1.ttl 
> http://localhost:3030/abc/data?graph=http://test1
> -- responds with 201 Created
> Then PUT some data into the second service  (fuseki:name 'abc123')
> curl -v -H "Content-type: text/turtle" --upload-file file2.ttl 
> http://localhost:3030/abc123/data?graph=http://test1
> - responds with 204 Created - indicating that the graph already existed 
> before this PUT.
> Checks on the contents of the two datasets indicate that the second PUT went 
> into the service 'abc', not into 'abc123'.
> Guess at possible cause: does the URL parsing in fuseki involve some kind of 
> simple regex which leads to 'abc' giving a successful match against 'abc123' 
> when it should not match?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to