You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Altmann, Michael" <Mi...@McKesson.com> on 2013/10/23 16:42:52 UTC
Use of recent features from httpclient
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
Re: Replacing FileManager (WAS use of recent features from httpclient)
Posted by Andy Seaborne <an...@apache.org>.
On 31/10/13 16:14, Andy Seaborne wrote:
> On 31/10/13 14:37, Altmann, Michael wrote:
>>
>> Here are three tests that show that altEntries in the global
>> FileManager are not honored by the StreamManager.
>> I have a file called myontology.ttl that looks like
>
> Thanks - I've created JENA-580 for this.
>
> A temporary workaround is to call "RIOT.init() ;" before anything else.
>
> Andy
Fixed in svn.
FileManager initializes RIOT (if available) before you can get the
global reference.
Andy
>
>>
>>
>> # imports: http://www.mckesson.com/life/snomed-ct.ontology.owl
>>
>> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>> @prefix owl: <http://www.w3.org/2002/07/owl#> .
>>
>> @prefix sct: <http://www.mckesson.com/life/snomed-ct.ontology.owl#> .
>> @prefix ex: <http://www.example.com#> .
>>
>> <http://www.example.com>
>> rdf:type owl:Ontology ;
>> owl:imports
>> <http://www.mckesson.com/life/snomed-ct.ontology.owl> .
>>
>>
>>
>> The SNOMED ontology is available on the classpath with the path
>> FactRepository/Common/models/snomed-ct.ttl .
>>
>>
>> The three test methods are shown below. The key observation is that
>> in the third one the
>> StreamsManager does not honor the altEntry and tries to resolve over
>> the internet.
>>
>>
>> /**
>> * Proves that setting an AltEntry in FileManager is honored by
>> FileManager
>> */
>> public void testLoadWithFileManagerFromAltEntry()
>> {
>> FileManager mgr = FileManager.get();
>> mgr.getLocationMapper().addAltEntry
>> ("http://www.mckesson.com/life/snomed-ct.ontology.owl",
>> "FactRepository/Common/models/snomed-ct.ttl");
>>
>> Model m = FileManager.get().loadModel(
>> "http://www.mckesson.com/life/snomed-ct.ontology.owl");
>> assertNotNull("Model should be non null", m);
>> assertTrue("Model should be non empty", m.size()>0);
>>
>> }
>>
>> /**
>> * Shows that setting up an AltEntry in StreamManager does get
>> honored by
>> * the StreamManager
>> */
>> public void testLoadOntologyWithStreamManagerFromAltEntry()
>> {
>> FileManager fileMgr = FileManager.get();
>> fileMgr.getLocationMapper().addAltEntry
>> ("http://www.mckesson.com/life/snomed-ct.ontology.owl",
>> "FactRepository/Common/models/snomed-ct.ttl");
>>
>> Model model = ModelFactory.createDefaultModel();
>>
>> InputStream stream =
>> getClass().getResourceAsStream("myontology.ttl");
>> model.read(stream, null, "TTL");
>>
>> StreamManager streamMgr =
>> StreamManager.makeDefaultStreamManager();
>> streamMgr.getLocationMapper().addAltEntry
>> ("http://www.mckesson.com/life/snomed-ct.ontology.owl",
>> "FactRepository/Common/models/snomed-ct.ttl");
>> StreamManager.setGlobal(streamMgr);
>>
>> /*
>> * No error is logged from OntDocumentManager
>> */
>> OntModel ont =
>> ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM_TRANS_INF, model);
>>
>> }
>>
>> /**
>> * Shows that setting up an AltEntry in FileManager does not get
>> honored by
>> * the StreamManager
>> */
>> public void testLoadOntologyWithFileManagerFromAltEntry()
>> {
>> FileManager fileMgr = FileManager.get();
>> fileMgr.getLocationMapper().addAltEntry
>> ("http://www.mckesson.com/life/snomed-ct.ontology.owl",
>> "FactRepository/Common/models/snomed-ct.ttl");
>>
>> Model model = ModelFactory.createDefaultModel();
>>
>> InputStream stream =
>> getClass().getResourceAsStream("myontology.ttl");
>> model.read(stream, null, "TTL");
>> /*
>> Logs
>> WARN OntDocumentManager:1077 - An error occurred while attempting to
>> read from http://www.mckesson.com/life/snomed-ct.ontology.owl. Msg was
>> '404 - not found'.
>> org.apache.jena.atlas.web.HttpException: 404 - not found
>> */
>> OntModel ont =
>> ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM_TRANS_INF, model);
>>
>> }
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Andy Seaborne [mailto:andy@apache.org]
>> Sent: Wednesday, October 30, 2013 4:11 PM
>> To: dev@jena.apache.org
>> Subject: Re: Replacing FileManager (WAS use of recent features from
>> httpclient)
>>
>> On 24/10/13 15:59, Altmann, Michael wrote:
>>> Thanks, I was not aware of the change. I have code that configures
>>> the global FileManager. It sets the locators, locations and
>>> prefixes. Should I change that code to only manipulate the global
>>> StreamManager or manipulate it in addition to the FileManager? I
>>> looked around in the documentation a bit, but I still see this page
>>> http://jena.apache.org/documentation/notes/file-manager.html , which
>>> focuses on the FileManager.
>>>
>>
>> At what point do you reconfigure the global FileManager? Before any
>> read/write atall? Maybe the reset is being doen after you changed it.
>> I've just looked at the code and I can believe the you can set the
>> global FileManager configuration, then cause RIOT to kick in and so
>> loose the configuration.
>>
>> If you call:
>>
>> IO_Jena.wireIntoJena()
>>
>> it explicitly forces the reconfiguration. It starts:
>>
>> FileManager.setGlobalFileManager(AdapterFileManager.get()) ;
>>
>> If that wortks, it'll confirm my suspicion and I can put in a
>> automatic kickstart.
>>
>> > http://jena.apache.org/documentation/notes/file-manager.html
>>
>> That could do with rewriting but it should be compatible.
>>
>> Andy
>>
>>>
>>> [This thread is probably evolving to something that ought to be on the
>>> users list. Should we move it? ]
>>
>>
>>>
>>>
>>> -----Original Message-----
>>> From: Rob Vesse [mailto:rvesse@dotnetrdf.org]
>>> Sent: Thursday, October 24, 2013 9:26 AM
>>> To: dev@jena.apache.org
>>> Subject: Re: Replacing FileManager (WAS use of recent features from
>>> httpclient)
>>>
>>> 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" <Mi...@McKesson.com>
>>> wrote:
>>>
>>>> [Altmann, Michael] ...
>>>
>>>
>>>
>>>
>>
>
Re: Replacing FileManager (WAS use of recent features from httpclient)
Posted by Andy Seaborne <an...@apache.org>.
On 31/10/13 14:37, Altmann, Michael wrote:
>
> Here are three tests that show that altEntries in the global FileManager are not honored by the StreamManager.
> I have a file called myontology.ttl that looks like
Thanks - I've created JENA-580 for this.
A temporary workaround is to call "RIOT.init() ;" before anything else.
Andy
>
>
> # imports: http://www.mckesson.com/life/snomed-ct.ontology.owl
>
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix owl: <http://www.w3.org/2002/07/owl#> .
>
> @prefix sct: <http://www.mckesson.com/life/snomed-ct.ontology.owl#> .
> @prefix ex: <http://www.example.com#> .
>
> <http://www.example.com>
> rdf:type owl:Ontology ;
> owl:imports <http://www.mckesson.com/life/snomed-ct.ontology.owl> .
>
>
>
> The SNOMED ontology is available on the classpath with the path FactRepository/Common/models/snomed-ct.ttl .
>
>
> The three test methods are shown below. The key observation is that in the third one the
> StreamsManager does not honor the altEntry and tries to resolve over the internet.
>
>
> /**
> * Proves that setting an AltEntry in FileManager is honored by FileManager
> */
> public void testLoadWithFileManagerFromAltEntry()
> {
> FileManager mgr = FileManager.get();
> mgr.getLocationMapper().addAltEntry
> ("http://www.mckesson.com/life/snomed-ct.ontology.owl",
> "FactRepository/Common/models/snomed-ct.ttl");
>
> Model m = FileManager.get().loadModel(
> "http://www.mckesson.com/life/snomed-ct.ontology.owl");
> assertNotNull("Model should be non null", m);
> assertTrue("Model should be non empty", m.size()>0);
>
> }
>
> /**
> * Shows that setting up an AltEntry in StreamManager does get honored by
> * the StreamManager
> */
> public void testLoadOntologyWithStreamManagerFromAltEntry()
> {
> FileManager fileMgr = FileManager.get();
> fileMgr.getLocationMapper().addAltEntry
> ("http://www.mckesson.com/life/snomed-ct.ontology.owl",
> "FactRepository/Common/models/snomed-ct.ttl");
>
> Model model = ModelFactory.createDefaultModel();
>
> InputStream stream = getClass().getResourceAsStream("myontology.ttl");
> model.read(stream, null, "TTL");
>
> StreamManager streamMgr = StreamManager.makeDefaultStreamManager();
> streamMgr.getLocationMapper().addAltEntry
> ("http://www.mckesson.com/life/snomed-ct.ontology.owl",
> "FactRepository/Common/models/snomed-ct.ttl");
> StreamManager.setGlobal(streamMgr);
>
> /*
> * No error is logged from OntDocumentManager
> */
> OntModel ont = ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM_TRANS_INF, model);
>
> }
>
> /**
> * Shows that setting up an AltEntry in FileManager does not get honored by
> * the StreamManager
> */
> public void testLoadOntologyWithFileManagerFromAltEntry()
> {
> FileManager fileMgr = FileManager.get();
> fileMgr.getLocationMapper().addAltEntry
> ("http://www.mckesson.com/life/snomed-ct.ontology.owl",
> "FactRepository/Common/models/snomed-ct.ttl");
>
> Model model = ModelFactory.createDefaultModel();
>
> InputStream stream = getClass().getResourceAsStream("myontology.ttl");
> model.read(stream, null, "TTL");
> /*
> Logs
> WARN OntDocumentManager:1077 - An error occurred while attempting to read from http://www.mckesson.com/life/snomed-ct.ontology.owl. Msg was '404 - not found'.
> org.apache.jena.atlas.web.HttpException: 404 - not found
> */
> OntModel ont = ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM_TRANS_INF, model);
>
> }
>
>
>
>
>
> -----Original Message-----
> From: Andy Seaborne [mailto:andy@apache.org]
> Sent: Wednesday, October 30, 2013 4:11 PM
> To: dev@jena.apache.org
> Subject: Re: Replacing FileManager (WAS use of recent features from httpclient)
>
> On 24/10/13 15:59, Altmann, Michael wrote:
>> Thanks, I was not aware of the change. I have code that configures the global FileManager. It sets the locators, locations and prefixes. Should I change that code to only manipulate the global StreamManager or manipulate it in addition to the FileManager? I looked around in the documentation a bit, but I still see this page http://jena.apache.org/documentation/notes/file-manager.html , which focuses on the FileManager.
>>
>
> At what point do you reconfigure the global FileManager? Before any read/write atall? Maybe the reset is being doen after you changed it.
> I've just looked at the code and I can believe the you can set the global FileManager configuration, then cause RIOT to kick in and so loose the configuration.
>
> If you call:
>
> IO_Jena.wireIntoJena()
>
> it explicitly forces the reconfiguration. It starts:
>
> FileManager.setGlobalFileManager(AdapterFileManager.get()) ;
>
> If that wortks, it'll confirm my suspicion and I can put in a automatic kickstart.
>
> > http://jena.apache.org/documentation/notes/file-manager.html
>
> That could do with rewriting but it should be compatible.
>
> Andy
>
>>
>> [This thread is probably evolving to something that ought to be on the
>> users list. Should we move it? ]
>
>
>>
>>
>> -----Original Message-----
>> From: Rob Vesse [mailto:rvesse@dotnetrdf.org]
>> Sent: Thursday, October 24, 2013 9:26 AM
>> To: dev@jena.apache.org
>> Subject: Re: Replacing FileManager (WAS use of recent features from
>> httpclient)
>>
>> 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" <Mi...@McKesson.com>
>> wrote:
>>
>>> [Altmann, Michael] ...
>>
>>
>>
>>
>
RE: Replacing FileManager (WAS use of recent features from
httpclient)
Posted by "Altmann, Michael" <Mi...@McKesson.com>.
Here are three tests that show that altEntries in the global FileManager are not honored by the StreamManager.
I have a file called myontology.ttl that looks like
# imports: http://www.mckesson.com/life/snomed-ct.ontology.owl
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix sct: <http://www.mckesson.com/life/snomed-ct.ontology.owl#> .
@prefix ex: <http://www.example.com#> .
<http://www.example.com>
rdf:type owl:Ontology ;
owl:imports <http://www.mckesson.com/life/snomed-ct.ontology.owl> .
The SNOMED ontology is available on the classpath with the path FactRepository/Common/models/snomed-ct.ttl .
The three test methods are shown below. The key observation is that in the third one the
StreamsManager does not honor the altEntry and tries to resolve over the internet.
/**
* Proves that setting an AltEntry in FileManager is honored by FileManager
*/
public void testLoadWithFileManagerFromAltEntry()
{
FileManager mgr = FileManager.get();
mgr.getLocationMapper().addAltEntry
("http://www.mckesson.com/life/snomed-ct.ontology.owl",
"FactRepository/Common/models/snomed-ct.ttl");
Model m = FileManager.get().loadModel(
"http://www.mckesson.com/life/snomed-ct.ontology.owl");
assertNotNull("Model should be non null", m);
assertTrue("Model should be non empty", m.size()>0);
}
/**
* Shows that setting up an AltEntry in StreamManager does get honored by
* the StreamManager
*/
public void testLoadOntologyWithStreamManagerFromAltEntry()
{
FileManager fileMgr = FileManager.get();
fileMgr.getLocationMapper().addAltEntry
("http://www.mckesson.com/life/snomed-ct.ontology.owl",
"FactRepository/Common/models/snomed-ct.ttl");
Model model = ModelFactory.createDefaultModel();
InputStream stream = getClass().getResourceAsStream("myontology.ttl");
model.read(stream, null, "TTL");
StreamManager streamMgr = StreamManager.makeDefaultStreamManager();
streamMgr.getLocationMapper().addAltEntry
("http://www.mckesson.com/life/snomed-ct.ontology.owl",
"FactRepository/Common/models/snomed-ct.ttl");
StreamManager.setGlobal(streamMgr);
/*
* No error is logged from OntDocumentManager
*/
OntModel ont = ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM_TRANS_INF, model);
}
/**
* Shows that setting up an AltEntry in FileManager does not get honored by
* the StreamManager
*/
public void testLoadOntologyWithFileManagerFromAltEntry()
{
FileManager fileMgr = FileManager.get();
fileMgr.getLocationMapper().addAltEntry
("http://www.mckesson.com/life/snomed-ct.ontology.owl",
"FactRepository/Common/models/snomed-ct.ttl");
Model model = ModelFactory.createDefaultModel();
InputStream stream = getClass().getResourceAsStream("myontology.ttl");
model.read(stream, null, "TTL");
/*
Logs
WARN OntDocumentManager:1077 - An error occurred while attempting to read from http://www.mckesson.com/life/snomed-ct.ontology.owl. Msg was '404 - not found'.
org.apache.jena.atlas.web.HttpException: 404 - not found
*/
OntModel ont = ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM_TRANS_INF, model);
}
-----Original Message-----
From: Andy Seaborne [mailto:andy@apache.org]
Sent: Wednesday, October 30, 2013 4:11 PM
To: dev@jena.apache.org
Subject: Re: Replacing FileManager (WAS use of recent features from httpclient)
On 24/10/13 15:59, Altmann, Michael wrote:
> Thanks, I was not aware of the change. I have code that configures the global FileManager. It sets the locators, locations and prefixes. Should I change that code to only manipulate the global StreamManager or manipulate it in addition to the FileManager? I looked around in the documentation a bit, but I still see this page http://jena.apache.org/documentation/notes/file-manager.html , which focuses on the FileManager.
>
At what point do you reconfigure the global FileManager? Before any read/write atall? Maybe the reset is being doen after you changed it.
I've just looked at the code and I can believe the you can set the global FileManager configuration, then cause RIOT to kick in and so loose the configuration.
If you call:
IO_Jena.wireIntoJena()
it explicitly forces the reconfiguration. It starts:
FileManager.setGlobalFileManager(AdapterFileManager.get()) ;
If that wortks, it'll confirm my suspicion and I can put in a automatic kickstart.
> http://jena.apache.org/documentation/notes/file-manager.html
That could do with rewriting but it should be compatible.
Andy
>
> [This thread is probably evolving to something that ought to be on the
> users list. Should we move it? ]
>
>
> -----Original Message-----
> From: Rob Vesse [mailto:rvesse@dotnetrdf.org]
> Sent: Thursday, October 24, 2013 9:26 AM
> To: dev@jena.apache.org
> Subject: Re: Replacing FileManager (WAS use of recent features from
> httpclient)
>
> 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" <Mi...@McKesson.com>
> wrote:
>
>> [Altmann, Michael] ...
>
>
>
>
Re: Replacing FileManager (WAS use of recent features from httpclient)
Posted by Andy Seaborne <an...@apache.org>.
On 24/10/13 15:59, Altmann, Michael wrote:
> Thanks, I was not aware of the change. I have code that configures the global FileManager. It sets the locators, locations and prefixes. Should I change that code to only manipulate the global StreamManager or manipulate it in addition to the FileManager? I looked around in the documentation a bit, but I still see this page http://jena.apache.org/documentation/notes/file-manager.html , which focuses on the FileManager.
>
At what point do you reconfigure the global FileManager? Before any
read/write atall? Maybe the reset is being doen after you changed it.
I've just looked at the code and I can believe the you can set the
global FileManager configuration, then cause RIOT to kick in and so
loose the configuration.
If you call:
IO_Jena.wireIntoJena()
it explicitly forces the reconfiguration. It starts:
FileManager.setGlobalFileManager(AdapterFileManager.get()) ;
If that wortks, it'll confirm my suspicion and I can put in a automatic
kickstart.
> http://jena.apache.org/documentation/notes/file-manager.html
That could do with rewriting but it should be compatible.
Andy
>
> [This thread is probably evolving to something that ought to be on the users list. Should we move it? ]
>
>
> -----Original Message-----
> From: Rob Vesse [mailto:rvesse@dotnetrdf.org]
> Sent: Thursday, October 24, 2013 9:26 AM
> To: dev@jena.apache.org
> Subject: Re: Replacing FileManager (WAS use of recent features from httpclient)
>
> 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" <Mi...@McKesson.com>
> wrote:
>
>> [Altmann, Michael] ...
>
>
>
>
RE: Replacing FileManager (WAS use of recent features from
httpclient)
Posted by "Altmann, Michael" <Mi...@McKesson.com>.
Thanks, I was not aware of the change. I have code that configures the global FileManager. It sets the locators, locations and prefixes. Should I change that code to only manipulate the global StreamManager or manipulate it in addition to the FileManager? I looked around in the documentation a bit, but I still see this page http://jena.apache.org/documentation/notes/file-manager.html , which focuses on the FileManager.
[This thread is probably evolving to something that ought to be on the users list. Should we move it? ]
-----Original Message-----
From: Rob Vesse [mailto:rvesse@dotnetrdf.org]
Sent: Thursday, October 24, 2013 9:26 AM
To: dev@jena.apache.org
Subject: Re: Replacing FileManager (WAS use of recent features from httpclient)
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" <Mi...@McKesson.com>
wrote:
>[Altmann, Michael] ...
Re: Use of recent features from httpclient
Posted by Rob Vesse <rv...@dotnetrdf.org>.
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" <Mi...@McKesson.com>
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:rvesse@dotnetrdf.org]
>Sent: Thursday, October 24, 2013 7:58 AM
>To: dev@jena.apache.org
>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" <Mi...@McKesson.com>
>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:rvesse@dotnetrdf.org]
>>Sent: Wednesday, October 23, 2013 10:30 AM
>>To: dev@jena.apache.org
>>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"
>><Mi...@McKesson.com>>
>>
>>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
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
Re: Replacing FileManager (WAS use of recent features from
httpclient)
Posted by Rob Vesse <rv...@dotnetrdf.org>.
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" <Mi...@McKesson.com>
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:rvesse@dotnetrdf.org]
>Sent: Thursday, October 24, 2013 7:58 AM
>To: dev@jena.apache.org
>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" <Mi...@McKesson.com>
>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:rvesse@dotnetrdf.org]
>>Sent: Wednesday, October 23, 2013 10:30 AM
>>To: dev@jena.apache.org
>>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"
>><Mi...@McKesson.com>>
>>
>>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
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
RE: Use of recent features from httpclient
Posted by "Altmann, Michael" <Mi...@McKesson.com>.
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:rvesse@dotnetrdf.org]
Sent: Thursday, October 24, 2013 7:58 AM
To: dev@jena.apache.org
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" <Mi...@McKesson.com>
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:rvesse@dotnetrdf.org]
>Sent: Wednesday, October 23, 2013 10:30 AM
>To: dev@jena.apache.org
>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"
><Mi...@McKesson.com>>
>
>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
>
>
>
>
>
>
>
>
Re: Use of recent features from httpclient
Posted by Rob Vesse <rv...@dotnetrdf.org>.
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" <Mi...@McKesson.com>
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:rvesse@dotnetrdf.org]
>Sent: Wednesday, October 23, 2013 10:30 AM
>To: dev@jena.apache.org
>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"
><Mi...@McKesson.com>>
>
>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
>
>
>
>
>
>
>
>
RE: Use of recent features from httpclient
Posted by "Altmann, Michael" <Mi...@McKesson.com>.
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:rvesse@dotnetrdf.org]
Sent: Wednesday, October 23, 2013 10:30 AM
To: dev@jena.apache.org
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" <Mi...@McKesson.com>>
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
Re: Use of recent features from httpclient
Posted by Rob Vesse <rv...@dotnetrdf.org>.
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" <Mi...@McKesson.com>
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