Ok, but can you not work around this as I suggested by creating your own HttpClient using the original workaround you proposed and then providing it to HttpOp.setDefaultHttpClient() thus avoiding Jena ever creating its own HttpClient and hitting the problematic code path?
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 >> >> >> >> >> >> >> >> > > > >
