[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
Okay, so we should be able to treat 'HttpClientBuilder' as a kind of config 
object. Set one up and pass it in the way you would pass in config (including 
authN).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
My understanding of the new 4.3+ API is that building per call should not 
be a burden.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
One question with passing in a builder is the extent to which clients will 
be reusable. Perhaps that's where setting a default client or using the 
custom-client-per-service feature (available now) would be helpful?


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
@rvesse so the proposal is operations that take a `HttpClient` and 
operations that take an `HttpClientBuilder` and `HttpAuthenticator`? (It seems 
odd that the can't get the setting out of an `HttpClient` to feed into a 
builder.)

`HttpAuthenticator.apply` takes a `HttpClientBuilder`.

That would work for me.

We have to change the existing design because `HttpClient` is now immutable.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
One question with passing in a builder is the extent to which clients will 
be reusable. Perhaps that's where setting a default client or using the 
custom-client-per-service feature (available now) would be helpful?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@afs Said "(It seems odd that the can't get the setting out of an 
HttpClient to feed into a builder.)"

YES. It is _intensely_ annoying. It seems like a massive oversight to me, 
but as far as I can tell, it is the case. What's worse, several other classes 
that are of not dissimilar character _do_ feature convenient copy/builder ops. 
(E.g. `oah.client.config.RequestConfig.copy(RequestConfig)`). I will be 
checking out whether they're correcting this for the 5-series. (Under dev now.)


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@afs Said "(It seems odd that the can't get the setting out of an 
HttpClient to feed into a builder.)"

YES. It is _intensely_ annoying. It seems like a massive oversight to me, 
but as far as I can tell, it is the case. What's worse, several other classes 
that are of not dissimilar character _do_ feature convenient copy/builder ops. 
(E.g. `oah.client.config.RequestConfig.copy(RequestConfig)`). I will be 
checking out whether they're correcting this for the 5-series. (Under dev now.)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
@rvesse so the proposal is operations that take a `HttpClient` and 
operations that take an `HttpClientBuilder` and `HttpAuthenticator`? (It seems 
odd that the can't get the setting out of an `HttpClient` to feed into a 
builder.)

`HttpAuthenticator.apply` takes a `HttpClientBuilder`.

That would work for me.

We have to change the existing design because `HttpClient` is now immutable.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@afs Yes, the addition of `HttpOp` methods as you describe is what I was 
thinking of. Not too much there, but enough to let people move their own 
`HttpContext`s around, which would be pretty darn handy for exactly the kind of 
authN scenarios that concern @rvesse .


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@afs Yes, the addition of `HttpOp` methods as you describe is what I was 
thinking of. Not too much there, but enough to let people move their own 
`HttpContext`s around, which would be pretty darn handy for exactly the kind of 
authN scenarios that concern @rvesse .


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Extended calling conventions for arithmetic functions in Jena Rules

[Paul Houle]

In the following docs:

https://jena.apache.org/documentation/inference/

The arithmetic builtins are described as such:

"Note that these do not run backwards, if in sum a and c are bound and b
is unbound then the test will fail rather than bind b to (c-a). This
could be fixed."

This is repeated in the source code for said functions.

https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/builtins/Sum.java

in that case at line 78.

My question is:  is the only reason this does not work because the
Builtin doesn't handle it,  or because the engine wouldn't be able to
work correctly if the Builtin was fixed?

-- 
  Paul Houle
  paul.ho...@ontology2.com

[jira] [Commented] (JENA-1209) Add "exclusive mode" for TDB

[A. Soroka (JIRA)]

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

A. Soroka commented on JENA-1209:
-

Right, I meant more that the other option would be: you can get exclusive mode 
immediately, and then when any transactions that were open at the time 
eventually try to commit, the underlying store will throw an exception and 
force them to abort instead. Actually, I wanted to recommend against that, so 
it's all good. Definitely the right approach was taken, I think, for whatever 
that's worth! {grin}

> Add "exclusive mode" for TDB
> 
>
> Key: JENA-1209
> URL: https://issues.apache.org/jira/browse/JENA-1209
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>
> In exclusive mode, the current thread is guaranteed there are no other read  
> or write transactions active.
> This allows specialized code to _*very*_ carefully manipulate the internals 
> of the database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1209) Add "exclusive mode" for TDB

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1209:
--

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/154#discussion_r70663415
  
--- Diff: 
jena-tdb/src/main/java/org/apache/jena/tdb/transaction/TransactionManager.java 
---
@@ -436,8 +469,96 @@ public void notifyAbort(Transaction transaction)
 switch ( transaction.getMode() )
 {
 case READ: break ;
-case WRITE: writersWaiting.release() ;
+case WRITE: releaseWriterLock();
+}
+}
+
+private void releaseWriterLock() {
+int x = writersWaiting.availablePermits() ;
+if ( x != 0 )
+throw new TDBTransactionException("TransactionCoordinator: 
Probably mismatch of enable/disableWriter calls") ;
+writersWaiting.release() ;
+}
+
+private boolean acquireWriterLock(boolean canBlock) {
+if ( ! canBlock )
+return writersWaiting.tryAcquire() ;
+try { 
+writersWaiting.acquire() ; 
+return true;
+} catch (InterruptedException e) { throw new 
TDBTransactionException(e) ; }
+}
+
+/** Block until no writers are active.
--- End diff --

Just a "wordsmithing" suggestion: this might be better as `waitForWriters` 
or the like. `disableWriters` sounds a bit like the caller is going to have 
some kind of actual impact on the outstanding writers, but in truth the caller 
is just waiting for them to finish on their own, right? Same for the next 
method.


> Add "exclusive mode" for TDB
> 
>
> Key: JENA-1209
> URL: https://issues.apache.org/jira/browse/JENA-1209
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>
> In exclusive mode, the current thread is guaranteed there are no other read  
> or write transactions active.
> This allows specialized code to _*very*_ carefully manipulate the internals 
> of the database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request #154: JENA-1209: Exclusive mode for TDB

[ajs6f]

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/154#discussion_r70663415
  
--- Diff: 
jena-tdb/src/main/java/org/apache/jena/tdb/transaction/TransactionManager.java 
---
@@ -436,8 +469,96 @@ public void notifyAbort(Transaction transaction)
 switch ( transaction.getMode() )
 {
 case READ: break ;
-case WRITE: writersWaiting.release() ;
+case WRITE: releaseWriterLock();
+}
+}
+
+private void releaseWriterLock() {
+int x = writersWaiting.availablePermits() ;
+if ( x != 0 )
+throw new TDBTransactionException("TransactionCoordinator: 
Probably mismatch of enable/disableWriter calls") ;
+writersWaiting.release() ;
+}
+
+private boolean acquireWriterLock(boolean canBlock) {
+if ( ! canBlock )
+return writersWaiting.tryAcquire() ;
+try { 
+writersWaiting.acquire() ; 
+return true;
+} catch (InterruptedException e) { throw new 
TDBTransactionException(e) ; }
+}
+
+/** Block until no writers are active.
--- End diff --

Just a "wordsmithing" suggestion: this might be better as `waitForWriters` 
or the like. `disableWriters` sounds a bit like the caller is going to have 
some kind of actual impact on the outstanding writers, but in truth the caller 
is just waiting for them to finish on their own, right? Same for the next 
method.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1209) Add "exclusive mode" for TDB

[Andy Seaborne (JIRA)]

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

Andy Seaborne commented on JENA-1209:
-

It waits for transactions to finish. There isn't a way to kill transactions 
(c.f. killing java threads).

There is a {{startExclusveMode}} that blocks until ready.

There is a {{tryExclusveMode}} that returns true/false and does not wait.

When entering exclusive mode, the journal is flushed.


> Add "exclusive mode" for TDB
> 
>
> Key: JENA-1209
> URL: https://issues.apache.org/jira/browse/JENA-1209
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>
> In exclusive mode, the current thread is guaranteed there are no other read  
> or write transactions active.
> This allows specialized code to _*very*_ carefully manipulate the internals 
> of the database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (JENA-1209) Add "exclusive mode" for TDB

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne reassigned JENA-1209:
---

Assignee: Andy Seaborne

> Add "exclusive mode" for TDB
> 
>
> Key: JENA-1209
> URL: https://issues.apache.org/jira/browse/JENA-1209
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>
> In exclusive mode, the current thread is guaranteed there are no other read  
> or write transactions active.
> This allows specialized code to _*very*_ carefully manipulate the internals 
> of the database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1209) Add "exclusive mode" for TDB

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-1209:
--

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/154

JENA-1209: Exclusive mode for TDB



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena tdb-exclusive

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/154.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #154


commit ee6a67864f784e6e2bbfc63eb8f96276a587fbe5
Author: Andy Seaborne 
Date:   2016-07-13T16:17:04Z

JENA-1209: Exclusive mode for TDB




> Add "exclusive mode" for TDB
> 
>
> Key: JENA-1209
> URL: https://issues.apache.org/jira/browse/JENA-1209
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Andy Seaborne
>
> In exclusive mode, the current thread is guaranteed there are no other read  
> or write transactions active.
> This allows specialized code to _*very*_ carefully manipulate the internals 
> of the database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request #154: JENA-1209: Exclusive mode for TDB

[afs]

GitHub user afs opened a pull request:

https://github.com/apache/jena/pull/154

JENA-1209: Exclusive mode for TDB



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/afs/jena tdb-exclusive

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jena/pull/154.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #154


commit ee6a67864f784e6e2bbfc63eb8f96276a587fbe5
Author: Andy Seaborne 
Date:   2016-07-13T16:17:04Z

JENA-1209: Exclusive mode for TDB




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@paulhoule One difficulty with `HttpRequestInterceptor` is a good thing to 
bring up-- in the newer HTTP Commons client APIs, clients are immutable and if 
you want to add, e.g., interceptors, you need to do that when you build your 
client. OTOH, you can "late add" authN of some kinds using the more specific 
machinery that HTTP Commons provides via the methods in `HttpClientContext`. 
The interceptor pattern is more general, but as noted, you have to set it up 
early in the process.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@paulhoule One difficulty with `HttpRequestInterceptor` is a good thing to 
bring up-- in the newer HTTP Commons client APIs, clients are immutable and if 
you want to add, e.g., interceptors, you need to do that when you build your 
client. OTOH, you can "late add" authN of some kinds using the more specific 
machinery that HTTP Commons provides via the methods in `HttpClientContext`. 
The interceptor pattern is more general, but as noted, you have to set it up 
early in the process.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@paulhoule There is `org.apache.http.HttpRequestInterceptor`, which I think 
is what HTTP Commons itself supplies for that kind of purpose. But there are 
also a host of parts built into the rest of the HTTP Commons client API for 
authN, some of which you probably already know, like 
`oah.client.CredentialsProvider` or `oah.auth.AuthScheme`.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@paulhoule There is `org.apache.http.HttpRequestInterceptor`, which I think 
is what HTTP Commons itself supplies for that kind of purpose. But there are 
also a host of parts built into the rest of the HTTP Commons client API for 
authN, some of which you probably already know, like 
`oah.client.CredentialsProvider` or `oah.auth.AuthScheme`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@rvesse : Basically, I think we share the same picture of the situation. I 
wouldn't claim that this new API presents quite the same "ergonomics" as what 
we now have. I think the heart of the matter is well-expressed by your 
characterization: "it replaces a nicely encapsulated API with requiring users 
to directly interact with a lower level API". The question is: is that okay? 
Because the concern here is HTTP/networking, and I think it's at least arguable 
that HTTP/networking really isn't a concern of Jena. It's something that Jena 
itself relies on a library to achieve, and I'm suggesting that we don't really 
gain all that much for our users by repacking that functionality, unless it is 
cheap to do and there is some kind of value we can add while so doing. (And 
obviously, I don't think that's so much the case here.)

You're quite right that complex authN schemes (and forms-based stuff is a 
good example) get a little more onerous for the user with this new API. I would 
suggest, though, that we can mitigate that pretty well with good examples and 
docs. Showing people how to get their cookie and then hand around the 
`HttpContext` that holds it shouldn't be too hard. I can put myself on the hook 
to write some examples in the tests (or some other appropriate place), if it 
would help with your concerns?


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
@rvesse : Basically, I think we share the same picture of the situation. I 
wouldn't claim that this new API presents quite the same "ergonomics" as what 
we now have. I think the heart of the matter is well-expressed by your 
characterization: "it replaces a nicely encapsulated API with requiring users 
to directly interact with a lower level API". The question is: is that okay? 
Because the concern here is HTTP/networking, and I think it's at least arguable 
that HTTP/networking really isn't a concern of Jena. It's something that Jena 
itself relies on a library to achieve, and I'm suggesting that we don't really 
gain all that much for our users by repacking that functionality, unless it is 
cheap to do and there is some kind of value we can add while so doing. (And 
obviously, I don't think that's so much the case here.)

You're quite right that complex authN schemes (and forms-based stuff is a 
good example) get a little more onerous for the user with this new API. I would 
suggest, though, that we can mitigate that pretty well with good examples and 
docs. Showing people how to get their cookie and then hand around the 
`HttpContext` that holds it shouldn't be too hard. I can put myself on the hook 
to write some examples in the tests (or some other appropriate place), if it 
would help with your concerns?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[paulhoule]

Github user paulhoule commented on the issue:

https://github.com/apache/jena/pull/151
  
@rvesse can authentication be handled by something like a Decorator?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user paulhoule commented on the issue:

https://github.com/apache/jena/pull/151
  
@rvesse can authentication be handled by something like a Decorator?


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user rvesse commented on the issue:

https://github.com/apache/jena/pull/151
  
It also potentially makes it much harder to define complex authentication 
schemes. Four example the current API allows you to define an authenticator 
that presents different credentials to different URLs e.g. I might need 
different credentials for accessing the `/query` and `/update` endpoints of a 
Fuseki instance. In the new API it seems I would have to manually manage this 
and make sure I present the right client or context to each API call or 
encapsulating object


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[rvesse]

Github user rvesse commented on the issue:

https://github.com/apache/jena/pull/151
  
It also potentially makes it much harder to define complex authentication 
schemes. Four example the current API allows you to define an authenticator 
that presents different credentials to different URLs e.g. I might need 
different credentials for accessing the `/query` and `/update` endpoints of a 
Fuseki instance. In the new API it seems I would have to manually manage this 
and make sure I present the right client or context to each API call or 
encapsulating object


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user rvesse commented on the issue:

https://github.com/apache/jena/pull/151
  
My major concern with this pull request is that it replaces a nicely 
encapsulated API with requiring users to directly interact with a lower level 
API. It seems like there should be room for compromise i.e. Keeping 
`HttpAuthenticator` but perhaps having it simply operate over a 
`HttpClientBuilder` instead

I am also unclear how more complex authentication such as forms based 
authentication which requires some sort of out of band login and presenting 
some token with each request e.g. a cookie. Part of the reason the original API 
was introduced by myself was that I needed to interact with systems that relied 
upon forms based authentication. As I understand that the proposed new API I 
would have to manage that login myself and pass the resulting `HttpContext` 
everywhere that needs it?


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[rvesse]

Github user rvesse commented on the issue:

https://github.com/apache/jena/pull/151
  
My major concern with this pull request is that it replaces a nicely 
encapsulated API with requiring users to directly interact with a lower level 
API. It seems like there should be room for compromise i.e. Keeping 
`HttpAuthenticator` but perhaps having it simply operate over a 
`HttpClientBuilder` instead

I am also unclear how more complex authentication such as forms based 
authentication which requires some sort of out of band login and presenting 
some token with each request e.g. a cookie. Part of the reason the original API 
was introduced by myself was that I needed to interact with systems that relied 
upon forms based authentication. As I understand that the proposed new API I 
would have to manage that login myself and pass the resulting `HttpContext` 
everywhere that needs it?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user rvesse commented on a diff in the pull request:

https://github.com/apache/jena/pull/151#discussion_r70629865
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/HttpQuery.java ---
@@ -298,6 +292,19 @@ public InputStream exec() throws QueryExceptionHTTP {
 throw jEx;
 }
 }
+
+private void contextualizeCompressionSettings() {
+final RequestConfig.Builder builder = 
RequestConfig.copy(context.getRequestConfig());
+builder.setContentCompressionEnabled(allowGZip || allowDeflate);
--- End diff --

Is it is the case that the two settings are no longer independent? If so 
why bother maintaining  independent settings?


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/151#discussion_r70630354
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/HttpQuery.java ---
@@ -298,6 +292,19 @@ public InputStream exec() throws QueryExceptionHTTP {
 throw jEx;
 }
 }
+
+private void contextualizeCompressionSettings() {
+final RequestConfig.Builder builder = 
RequestConfig.copy(context.getRequestConfig());
+builder.setContentCompressionEnabled(allowGZip || allowDeflate);
--- End diff --

It's a very fair point. I was trying to be very light in my changes to the 
API, but this is confusing. I'll fix it by going to a single `allowCompression` 
setting.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request #151: JENA-576: Moving away from deprecated HttpCommons Cl...

[ajs6f]

Github user ajs6f commented on a diff in the pull request:

https://github.com/apache/jena/pull/151#discussion_r70630354
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/HttpQuery.java ---
@@ -298,6 +292,19 @@ public InputStream exec() throws QueryExceptionHTTP {
 throw jEx;
 }
 }
+
+private void contextualizeCompressionSettings() {
+final RequestConfig.Builder builder = 
RequestConfig.copy(context.getRequestConfig());
+builder.setContentCompressionEnabled(allowGZip || allowDeflate);
--- End diff --

It's a very fair point. I was trying to be very light in my changes to the 
API, but this is confusing. I'll fix it by going to a single `allowCompression` 
setting.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-1209) Add "exclusive mode" for TDB

[A. Soroka (JIRA)]

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

A. Soroka commented on JENA-1209:
-

Would this be something where a request for exclusive mode blocks until all 
open transactions close, or would it somehow fail out and abort any open 
transactions so as to proceed immediately?

> Add "exclusive mode" for TDB
> 
>
> Key: JENA-1209
> URL: https://issues.apache.org/jira/browse/JENA-1209
> Project: Apache Jena
>  Issue Type: Bug
>Reporter: Andy Seaborne
>
> In exclusive mode, the current thread is guaranteed there are no other read  
> or write transactions active.
> This allows specialized code to _*very*_ carefully manipulate the internals 
> of the database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request #151: JENA-576: Moving away from deprecated HttpCommons Cl...

[rvesse]

Github user rvesse commented on a diff in the pull request:

https://github.com/apache/jena/pull/151#discussion_r70629865
  
--- Diff: 
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/HttpQuery.java ---
@@ -298,6 +292,19 @@ public InputStream exec() throws QueryExceptionHTTP {
 throw jEx;
 }
 }
+
+private void contextualizeCompressionSettings() {
+final RequestConfig.Builder builder = 
RequestConfig.copy(context.getRequestConfig());
+builder.setContentCompressionEnabled(allowGZip || allowDeflate);
--- End diff --

Is it is the case that the two settings are no longer independent? If so 
why bother maintaining  independent settings?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
The need for closing responses isn't new - all typed input streams should 
be closed in the codebase currently because I had to go hunting them all down 
with the old `HttpOp` code.  So, hopefully, theer are no issues here.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1209) Add "exclusive mode" for TDB

[Andy Seaborne (JIRA)]

Andy Seaborne created JENA-1209:
---

 Summary: Add "exclusive mode" for TDB
 Key: JENA-1209
 URL: https://issues.apache.org/jira/browse/JENA-1209
 Project: Apache Jena
  Issue Type: Bug
Reporter: Andy Seaborne


In exclusive mode, the current thread is guaranteed there are no other read  or 
write transactions active.

This allows specialized code to _*very*_ carefully manipulate the internals of 
the database.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
So to check my understanding:

For each operation that takes a `HttpClient` there is one that takes a 
`HttpClient` and an `HttpContext`.

Not so bad - we don't have the `HttpAutheticator` ones any more. 

Of course, if java had default parameters values like scala ...



> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
So to check my understanding:

For each operation that takes a `HttpClient` there is one that takes a 
`HttpClient` and an `HttpContext`.

Not so bad - we don't have the `HttpAutheticator` ones any more. 

Of course, if java had default parameters values like scala ...



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (JENA-576) Upgrade Apache HTTP Client to 4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on JENA-576:
-

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
Right, I think we're fine as long as Jena itself is actually the client 
(e.g. as part of `SERVICE` action in a query). It was the situation in which 
some app is using HTTP via `HttpOp` in which an input stream could "leak". But 
I think that's really just not Jena's problem, right? If you walk away with a 
resource from the network, you need to deal with it properly. Jena can't run 
after you pulling on your shirt to remind you.


> Upgrade Apache HTTP Client to 4.3
> -
>
> Key: JENA-576
> URL: https://issues.apache.org/jira/browse/JENA-576
> Project: Apache Jena
>  Issue Type: Dependency upgrade
>  Components: ARQ
>Affects Versions: Jena 2.11.0
>Reporter: Rob Vesse
>Assignee: Rob Vesse
>Priority: Minor
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> As of 2.11.0 ARQ centralizes all HTTP operations through HttpOp which relies 
> on Apache HTTP Client.  Currently we are using 4.2.3 while the latest stable 
> release is actually 4.3.1
> Therefore we should look at upgrading our code to use the latest version 
> which may entail some refactoring since there appears to have been some 
> breaking changes across the minor version bump which users have seen in usage 
> - e.g. 
> https://github.com/pyvandenbussche/sparqles/issues/9#issuecomment-27220738



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/151
  
Right, I think we're fine as long as Jena itself is actually the client 
(e.g. as part of `SERVICE` action in a query). It was the situation in which 
some app is using HTTP via `HttpOp` in which an input stream could "leak". But 
I think that's really just not Jena's problem, right? If you walk away with a 
resource from the network, you need to deal with it properly. Jena can't run 
after you pulling on your shirt to remind you.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #151: JENA-576: Moving away from deprecated HttpCommons Client AP...

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/151
  
The need for closing responses isn't new - all typed input streams should 
be closed in the codebase currently because I had to go hunting them all down 
with the old `HttpOp` code.  So, hopefully, theer are no issues here.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (JENA-1203) projecting non grouped variable in subquery is incorrectly allowed

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-1203.
-
   Resolution: Fixed
Fix Version/s: Jena 3.1.1

Not just GROUP BY usage - also varibables in BIND are now checked as for 
queries.

> projecting non grouped variable in subquery is incorrectly allowed
> --
>
> Key: JENA-1203
> URL: https://issues.apache.org/jira/browse/JENA-1203
> Project: Apache Jena
>  Issue Type: Bug
> Environment: sparql.org's validator
>Reporter: Joshua Taylor
>Assignee: Andy Seaborne
>Priority: Minor
> Fix For: Jena 3.1.1
>
>
> Described in this Stack Overflow answer, 
> http://stackoverflow.com/a/38104783/1281433 :
> {code}
> SELECT ?sub ?pred ?obj (count(?obj) as ?count)
> WHERE { ?sub ?pred ?obj .
> } GROUP BY ?sub
> {code}
> is illegal, because there are non-grouped variables in the projection (?pred, 
> ?obj).  However, when this query appears as a subquery, no syntax error is 
> reported, as in:
> {code}
> DELETE { ?sub ?pred ?obj . } 
> WHERE {  
> {SELECT ?sub ?pred ?obj (count(?obj) as ?count)
> WHERE { ?sub ?pred ?obj .
> } GROUP BY ?sub
> } FILTER(?count < 14)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1203) projecting non grouped variable in subquery is incorrectly allowed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on JENA-1203:
---

Commit 9355372b2c3cc74a6f950ca022290584cf3179d3 in jena's branch 
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=9355372 ]

JENA-1203: Another update syntax test


> projecting non grouped variable in subquery is incorrectly allowed
> --
>
> Key: JENA-1203
> URL: https://issues.apache.org/jira/browse/JENA-1203
> Project: Apache Jena
>  Issue Type: Bug
> Environment: sparql.org's validator
>Reporter: Joshua Taylor
>Assignee: Andy Seaborne
>Priority: Minor
>
> Described in this Stack Overflow answer, 
> http://stackoverflow.com/a/38104783/1281433 :
> {code}
> SELECT ?sub ?pred ?obj (count(?obj) as ?count)
> WHERE { ?sub ?pred ?obj .
> } GROUP BY ?sub
> {code}
> is illegal, because there are non-grouped variables in the projection (?pred, 
> ?obj).  However, when this query appears as a subquery, no syntax error is 
> reported, as in:
> {code}
> DELETE { ?sub ?pred ?obj . } 
> WHERE {  
> {SELECT ?sub ?pred ?obj (count(?obj) as ?count)
> WHERE { ?sub ?pred ?obj .
> } GROUP BY ?sub
> } FILTER(?count < 14)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (JENA-1203) projecting non grouped variable in subquery is incorrectly allowed

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne reassigned JENA-1203:
---

Assignee: Andy Seaborne

> projecting non grouped variable in subquery is incorrectly allowed
> --
>
> Key: JENA-1203
> URL: https://issues.apache.org/jira/browse/JENA-1203
> Project: Apache Jena
>  Issue Type: Bug
> Environment: sparql.org's validator
>Reporter: Joshua Taylor
>Assignee: Andy Seaborne
>Priority: Minor
>
> Described in this Stack Overflow answer, 
> http://stackoverflow.com/a/38104783/1281433 :
> {code}
> SELECT ?sub ?pred ?obj (count(?obj) as ?count)
> WHERE { ?sub ?pred ?obj .
> } GROUP BY ?sub
> {code}
> is illegal, because there are non-grouped variables in the projection (?pred, 
> ?obj).  However, when this query appears as a subquery, no syntax error is 
> reported, as in:
> {code}
> DELETE { ?sub ?pred ?obj . } 
> WHERE {  
> {SELECT ?sub ?pred ?obj (count(?obj) as ?count)
> WHERE { ?sub ?pred ?obj .
> } GROUP BY ?sub
> } FILTER(?count < 14)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena issue #150: [JENA-1204] support for multiple BuiltinRegistry for differ...

[der]

Github user der commented on the issue:

https://github.com/apache/jena/pull/150
  
Thanks for the ping. I've seen it but not had time to look at yet.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---