Michael
The issue is that recent versions of Jena delegate IO to ARQs RIOT
subsystem which has a separate StreamManager which manages how resources
are opened.
You can replace this like so:
StreamManager mgr = StreamManager.makeDefaultStreamManager();
// Clear out default setup
mgr.clearLocators();
// Add back ability to read from files
mgr.addLocator(new LocatorFile(null));
// Optionally add back ability to read from class path
mgr.addLocator(new
LocatorClassLoader(StreamManager.getClass().getClassLoader()));
StreamManager.setGlobal(mgr);
Hope this helps,
Rob
On 24/10/2013 14:45, "Altmann, Michael" <[email protected]>
wrote:
>This took a bit of digging. See the stack trace below. You are right,
>jena is not directly calling SchemeRegistryFactory.createSystemDefault().
> The problem is that HttpOp.exec is calling httpClient.execute, which
>ends up calling SchemeRegistryFactory.createSystemDefault(). Evidently
>my class loaded already picked up the older version of
>SchemeRegistryFactory from the GWT jar and therefore I get the
>NoSuchMethodError. So my only hope is to avoid calls to HttpOp.exec.
>
>
>So that leads to the other thing that has been bothering me. The default
>FileManager uses a LocatorURL and therefore tries to go out to the
>internet to resolve URLs that are in ontologies. This problem was
>somewhat bad when we upgraded to 2.7.3 and is even worse in 2.11.0 I
>have been unsuccessful in overwriting the default FileManager with my own
>locationEntries before OntModel machinery loads URLs. Have there been
>deliberate changes in this behavior and is there a recommended way to set
>up an application that needs to run behind a firewall without access to
>the internet? The application needs to be able to create Ont models that
>use rdfs and owl. The application also reads some RDF files that have
>prefixes that are not real URLs, like this
>
>@prefix sct: <http://www.mckesson.com/life/snomed-ct.ontology.owl#> .
>
>
>
>
>Thread [main] (Suspended (exception NoSuchMethodError))
> owns: SystemDefaultHttpClient (id=89)
> owns: ConcurrentHashMap<K,V> (id=49)
> owns: Object (id=50)
> owns: ContextCache (id=51)
> SystemDefaultHttpClient.createClientConnectionManager() line: 118
> SystemDefaultHttpClient(AbstractHttpClient).getConnectionManager() line:
>445
> SystemDefaultHttpClient(AbstractHttpClient).createHttpContext() line:
>274
> SystemDefaultHttpClient(AbstractHttpClient).execute(HttpHost,
>HttpRequest, HttpContext) line: 797
> SystemDefaultHttpClient(AbstractHttpClient).execute(HttpUriRequest,
>HttpContext) line: 754
> HttpOp.exec(String, HttpUriRequest, String, HttpResponseHandler,
>HttpClient, HttpContext, HttpAuthenticator) line: 1011
> HttpOp.execHttpGet(String, String, HttpResponseHandler, HttpClient,
>HttpContext, HttpAuthenticator) line: 291
> HttpOp.execHttpGet(String, String) line: 326
> LocatorURL.open(String) line: 46
> StreamManager.openNoMapOrNull(String) line: 138
> StreamManager.open(String) line: 99
> RDFDataMgr.open(String, StreamManager) line: 783
> RDFDataMgr.open(String, Context) line: 772
> RDFDataMgr.parse(StreamRDF, String, String, Lang, Context) line: 676
> RDFDataMgr.read(Graph, String, String, Lang, Context) line: 211
> RDFDataMgr.read(Graph, String, Lang, Context) line: 184
> RDFDataMgr.read(Graph, String, Lang) line: 122
> RDFDataMgr.read(Model, String, Lang) line: 113
> JenaReadersWriters$RDFReaderRIOT_RDFXML(RDFReaderRIOT).read(Model,
>String) line: 77
> ModelCom.read(String) line: 229
> AdapterFileManager.readModelWorker(Model, String, String, String) line:
>277
> AdapterFileManager(FileManager).loadModelWorker(String, String, String)
>line: 326
> AdapterFileManager(FileManager).loadModel(String) line: 278
>
>
>
>
>
>-----Original Message-----
>From: Rob Vesse [mailto:[email protected]]
>Sent: Thursday, October 24, 2013 7:58 AM
>To: [email protected]
>Subject: Re: Use of recent features from httpclient
>
>Michael
>
>The method you identify is only used in test code, it is not called
>anywhere in the main ARQ code base (or the main code base of any other
>Jena library for that matter)
>
>As I suggested before if you could provide a stack trace that shows the
>exact error you receive in your environment so we can see where the call
>to that method comes from and look at how to avoid it (if at all
>possible) that would be much appreciated. Note also that you can provide
>a HttpClient instance to use via the HttpOp.setDefaultHttpClient() which
>may allow you to work around this without any need for changes on our
>part.
>
>Thanks,
>
>Rob
>
>
>
>On 23/10/2013 18:40, "Altmann, Michael" <[email protected]>
>wrote:
>
>>In org.apache.jena.riot.web.HttpOp there is a call to
>>SchemeRegistryFactory.createSystemDefault(). This method is new in
>>HTTPClient 4.2.
>>
>> public static HttpClient createCachingHttpClient() {
>>
>> return new SystemDefaultHttpClient() {
>>
>> /** See SystemDefaultHttpClient (4.2). This version always
>>sets the connection cache */
>>
>> @Override
>>
>> protected ClientConnectionManager
>>createClientConnectionManager() {
>>
>> PoolingClientConnectionManager connmgr = new
>>PoolingClientConnectionManager(
>>
>> SchemeRegistryFactory.createSystemDefault());
>>
>> String s = System.getProperty("http.maxConnections",
>> "5");
>>
>> int max = Integer.parseInt(s);
>>
>> connmgr.setDefaultMaxPerRoute(max);
>>
>> connmgr.setMaxTotal(2 * max);
>>
>> return connmgr;
>>
>> }
>>
>> } ;
>>
>> } ;
>>
>>
>>
>>
>>
>>
>>If you would be willing to replicate the code that is in httpclient
>>4.2+, rather than calling SchemeRegistryFactory.createSystemDefault(),
>>I would be much obliged. The code in SchemeRegistryFactory is
>>
>> public static SchemeRegistry More ...createSystemDefault() {
>> SchemeRegistry registry = new SchemeRegistry();
>> registry.register(
>> new Scheme("http", 80,
>>PlainSocketFactory.getSocketFactory()));
>> registry.register(
>> new Scheme("https", 443,
>>SSLSocketFactory.getSystemSocketFactory()));
>> return registry;
>> }
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: Rob Vesse [mailto:[email protected]]
>>Sent: Wednesday, October 23, 2013 10:30 AM
>>To: [email protected]
>>Subject: Re: Use of recent features from httpclient
>>
>>
>>
>>We are always open to making the code as widely compatible as possible.
>>
>>Could you point out where we call the troublesome method or provide a
>>relevant stack trace from your environment?
>>
>>
>>
>>It's possible that this is something that gets called by the internals
>>of HTTP Client in which case we would likely not be able to change this.
>>
>>
>>
>>Rob
>>
>>
>>
>>On 23/10/2013 15:42, "Altmann, Michael"
>><[email protected]<mailto:[email protected]>>
>>
>>wrote:
>>
>>
>>
>>>Sometime between version 2.7.3 and 2.11.0, jena upgraded the version
>>>of
>>
>>>the apache httpclient library. It now uses 4.2.3. In particular, it
>>
>>>calls a method that was added in the 4.2 version of httpclient, namely
>>
>>>org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault().
>>
>>>
>>
>>>While that is a completely reasonable thing to do from the Jena
>>
>>>development point of view, it is causing us trouble. Our application
>>
>>>uses Jena and also uses GWT (Google Web Toolkit). Even the most
>>>recent
>>
>>>version of GWT ( 2.5.1) comes packaged with an old, 4.0, version of
>>>the
>>
>>>org.apache.http.impl.conn.SchemeRegistryFactory class, which lacks the
>>
>>>createSystemDefault() method. This means that we cannot use Jena
>>
>>>beyond version 2.7.3 until GWT Fixes its packaging (see
>>
>>>https://code.google.com/p/google-web-toolkit/issues/detail?id=4484).
>>
>>>There are several bug fixes in recent versions of Jena that I would
>>
>>>love to pick up, but cannot. Is there any chance that Jena would be
>>
>>>willing to develop against httpclient is a way that is backwards
>>
>>>compatible with httpclient 4.0?
>>
>>>
>>
>>>Thanks, Michael Altmann
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
