Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/175
Fixed in Apache Git with f659ca8c16f030dcf4e1a1f547f2dfaefb092fdf
---
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
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/175
If it don't work, it don't work. I'll pull that line out, along with the
IRC stanza.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Hm. This is really quite squirrely. If there is something subtle wrong with
`ServerTest::resetServer`, I wonder what I did in my PR to make it show up?
Anyway, I will start tracing it. Thanks
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
That stuff in `AbstractRemoteEndpointResultSetTests` is cruft-- client
swapping is taken care of in `TS_JdbcDriverRemote` itself. But it doesn't seem
to have any effect on the mysterious failures. But I
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
It's as though some kind of static state is being impacted. But where?!?!
---
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
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Yes, I can get it to fail with
```
@RunWith(Suite.class)
@Suite.SuiteClasses({ TestRemoteEndpointConnection.class,
TestRemoteEndpointConnection.class })
public class TestSpecial
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/176
> Unless there is a good reason to make the 2 permissions methods static I
would prefer to leave them alone.
I had some reason (explained above) but since seems less clear to you, I
will rem
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82511823
--- Diff:
jena-permissions/src/main/java/org/apache/jena/permissions/impl/SecuredItemImpl.java
---
@@ -299,7 +299,7 @@ public String toString() throws
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82511824
--- Diff:
jena-permissions/src/main/java/org/apache/jena/permissions/impl/SecuredItemImpl.java
---
@@ -312,7 +312,7 @@ private Boolean cacheGet(final CacheKey
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/176
The bulk of changes to `jena-permissions` are using `<>` instead of writing
out type parameters, but there are also a few more substantive syntax and other
changes there.
---
If your project is
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82511008
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/validation/DataValidator.java
---
@@ -101,33 +95,6 @@ protected JsonObject execute
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82511001
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/server/FusekiServer.java
---
@@ -162,10 +162,6
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82511004
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/server/FusekiServer.java
---
@@ -371,19 +367,6 @@ else if ( ! dir.isDirectory
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82510986
--- Diff: jena-base/src/test/java/org/apache/jena/atlas/lib/TestHex.java ---
@@ -85,7 +85,7 @@ private static void testStr2Val(String str, int expected
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82511000
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/server/FusekiServer.java
---
@@ -371,19 +367,6 @@ else if ( ! dir.isDirectory
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82510977
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/engine/iterator/QueryIterTopN.java
---
@@ -74,7 +74,7 @@ public QueryIterTopN(QueryIterator qIter
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82510973
--- Diff: jena-base/src/main/java/org/apache/jena/atlas/io/BlockUTF8.java
---
@@ -227,11 +220,6 @@ else if ( ch <= 0x7FFF )
}
//
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/176#discussion_r82510971
--- Diff: jena-base/src/main/java/org/apache/jena/atlas/io/BlockUTF8.java
---
@@ -154,11 +152,6 @@ else if ( (x & 0xF8) ==
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/176
I will try to fix these things sometime tomorrow in another commit,
especially if I can fix #151.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
I can't get the deadlocking to occur, but by running tests in the order you
give, I can see the three failures in
`TestRemoteEndpointConnectionWithResultSetTypes`. I don't see anything special
about
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Wow, this is getting quite weird. I don't get any of that stuff. I will get
on this and find out why. Deadlock is really unexpected!
---
If your project is set up for it, you can reply to this email
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/176
Absolutely. Would you rather I just left it here and we can pick it up at
the right moment, or close this PR and reopen it post-release?
---
If your project is set up for it, you can reply
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/176
A few more commits to come this afternoon.
---
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
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/176
Minor cleanup
Just removing dead code and variables that don't get used, adding `static`
here or there to clarify tests a bit, that sort of thing. Pruning.
You can merge this pull request into a Git
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/151#discussion_r82506306
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/QueryEngineHTTP.java
---
@@ -135,8 +135,7 @@ private QueryEngineHTTP(String serviceURI
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/151#discussion_r82505814
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/QueryEngineHTTP.java
---
@@ -135,8 +135,7 @@ private QueryEngineHTTP(String serviceURI
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/151#discussion_r82505751
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/QueryEngineHTTP.java
---
@@ -135,8 +135,7 @@ private QueryEngineHTTP(String serviceURI
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Just as an example, I could imagine supporting fluent methods that would
let people use Jena's language selection machinery (i.e. `Lang`) instead of
using HTTP `Accept` directly.
---
If your project
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Like I said, I'm fine with making a new fluent API. Can you describe some
of the things you see as common in particular to a semweb app? `HttpOp` as it
stands doesn't appear to do anything particular
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/151#discussion_r82505343
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/QueryEngineHTTP.java
---
@@ -135,8 +135,7 @@ private QueryEngineHTTP(String serviceURI
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/151#discussion_r82504994
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/QueryEngineHTTP.java
---
@@ -135,8 +135,7 @@ private QueryEngineHTTP(String serviceURI
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/151#discussion_r82504973
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/QueryEngineHTTP.java
---
@@ -135,8 +135,7 @@ private QueryEngineHTTP(String serviceURI
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
And as a point of info, I didn't actually end up changing the `HttpOp` API
all that much, just `HttpAuthenticator` => `HttpClient`. The additional
parameters for `HttpContext` turned out to alre
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
I'm totally fine with a "high-level" rethink, but at some point, aren't we
just duplicating this:
https://hc.apache.org/httpcomponents-client-ga/tutorial/html/fluent.html
?
---
If yo
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
As for the fix, specifically I went to `HttpOp` and made sure that any HTTP
clients built there get closed properly. HTTP clients that get passed in don't
get closed because that's the job of the client
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Sorry, @afs , I'm working on this now but not keeping this conversation up
to date. In fact, my most recent comment I now believe to have been wrong. See
[here](https://hc.apache.org/httpcomponents
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/175#discussion_r82504509
--- Diff: .travis.yml ---
@@ -0,0 +1,18 @@
+language: java
+sudo: false
+script: mvn -Pdev verify
+jdk:
+ - oraclejdk8
+ - openjdk8
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/175#discussion_r82504407
--- Diff: .travis.yml ---
@@ -0,0 +1,18 @@
+language: java
+sudo: false
+script: mvn -Pdev verify
+jdk:
+ - oraclejdk8
+ - openjdk8
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/175
Added .travis.yml
https://issues.apache.org/jira/browse/JENA-1241
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/jena TravisCI
Alternatively
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Erm, good/bad news.
1. I can fix the problem @afs found.
2. I don't want to, because I realize now that I did this whole PR wrong.
If you read up this page, you'll see where both
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Got a fix, but I still need to make sure that I didn't break anything else
and that I'm not wasting resources and I'm hitting EOB for the day. I will send
a commit tomorrow morning (EST). Thanks
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
I've been able to reproduce. Investigating...
---
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
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Weird. Maybe something changed out from under me. This is a pretty old PR.
I'll get on it (thanks for the diagnostic info).
---
If your project is set up for it, you can reply to this email and have
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Ooh, just noticed that. I will take a look at it today and fix 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
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
It would be great if you could use this stuff in RDFConnector to trial 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
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Yes, as I understand it, we can merge. I haven't merged it because I try
never to merge my own stuff unless it's pretty trivial.
---
If your project is set up for it, you can reply to this email
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/171
Made changes in response to your review, @afs . If you have no further
objections, I'll merge this.
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/171
Now that we have #139 in, I'll add a further commit addressing your points.
Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/139
@fpservant, No, using that button, you can send a patch for the page now,
but it will not be applied until the trigger is pulled to republish the docs
pages. That will happen for the release
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@rvesse That is _exactly_ what has slowed this down! :)
---
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
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Code-wise, not that I know of. But I promised @rvesse examples of doing
form-based authN for query endpoints. If we're okay with those appearing in
docs (instead of the test suite) then I think we could
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/170
ð
---
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
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/170
Sorry @afs -- I am not used to Github's new "review" mode. I made some
comments a while ago, but apparently, I didn't press "Finish review" so you
never saw them!
---
If yo
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/170#discussion_r79304304
--- Diff:
jena-arq/src/test/java/org/apache/jena/sparql/transaction/AbstractTestTransactionIsolation.java
---
@@ -0,0 +1,55 @@
+/*
+ * Licensed
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/170#discussion_r80697618
--- Diff:
jena-arq/src/test/java/org/apache/jena/sparql/transaction/AbstractTestTransPromote.java
---
@@ -270,15 +281,30 @@ private void run_08(boolean b
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/171
Yes, certainly I'll hold off-- I have no idea how I missed that, especially
given that I just pointed out that JSON-LD PR to a colleague in a downstream
project yesterday!
---
If your project is set
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/171#discussion_r80686831
--- Diff: jena-arq/src/main/java/org/apache/jena/atlas/test/Gen.java ---
@@ -32,52 +38,35 @@
return rand(numRand, low, high, false
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/171#discussion_r80686815
--- Diff: jena-arq/src/main/java/org/apache/jena/atlas/test/Gen.java ---
@@ -95,19 +84,13 @@
}
if ( !found
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/171
Using library code in a few classes
Just a couple of orthogonal commits that use library code in `Collections`,
switch to using `default` methods where it seems appropriate, remove
assignments
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/commit/2610908744464e1247b2896f7b26e78cadf56d84#commitcomment-19102402
In
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/DatasetGraphInMemory.java:
In
jena-arq/src/main/java/org/apache/jena
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/commit/2610908744464e1247b2896f7b26e78cadf56d84#commitcomment-19102347
In
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/DatasetGraphInMemory.java:
In
jena-arq/src/main/java/org/apache/jena
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/168#discussion_r78070911
--- Diff:
jena-core/src/main/java/org/apache/jena/graph/impl/TransactionHandlerBase.java
---
@@ -36,21 +40,45 @@ public TransactionHandlerBase
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/165#discussion_r76616848
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/algebra/optimize/Optimize.java ---
@@ -18,82 +18,58 @@
package
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/165#discussion_r76602821
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/algebra/optimize/Optimize.java ---
@@ -18,82 +18,58 @@
package
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/164#discussion_r75602598
--- Diff:
jena-tdb/src/main/java/org/apache/jena/tdb/transaction/TransactionManager.java
---
@@ -613,21 +652,43 @@ public void flush
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/163
JENA-1225: Remove prefix map when graph is deleted in TIM
JENA-1225: Remove prefix map when graph is deleted in TIM
You can merge this pull request into a Git repository by running:
$ git pull
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/161
Okay, I'll hang tight.
---
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
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/161
Oh, okay, I get it now. And even if you could block, as you wrote above,
that could be a really long time in some cases. Do you want me to write
something for TIM to bring a version number
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/161
I guess I'm confused as to why one can't determine (from the version
numbers) whether another transaction has committed? If you know a transaction's
version number and you know the transaction manager's
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/161
So ideally, it would be another writer _committing_ that would throw a
switch to refuse promotion to extant transactions? Instead of another writer
simple existing?
---
If your project is set up
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/160
Fixed out-of-Github via
https://git-wip-us.apache.org/repos/asf?p=jena.git;a=commit;h=e385a0dec7d04c582283d21fdf1923bf937a52db
---
If your project is set up for it, you can reply to this email and have
Github user ajs6f closed the pull request at:
https://github.com/apache/jena/pull/160
---
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
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/161
I like the proposal, basically, although I suspect it might be a little
tricky to do the original suggestion of "limited read committed" in current
TIM. Adding `readCurrent` would make se
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/161
Sorry, I let this go without replying. No, the
`DatasetGraphTransaction.promotion` isn't really my concern. It's the fact that
you start a read transaction on a dataset, then try to write, and instead
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/161
At first look, I would prefer the second option for dealing with
intervening writes. It's blunter, but it seems a good deal easier for
application writers to reason about. But maybe I'm not giving
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/161
Hm, just a first gut reaction about that example API: I would not want to
initiate a promotion just by signalling system-wide and then writing. I'd much
rather some positive step be taken _on
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/160
JENA-1189: Resolve problems with jena-jdbc-driver-tdb tests on Macs
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/jena JENA-1189-2
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Okay. sounds like I owe the following work for this:
- Enriching `HttpOp` to include methods that accept `HttpContext`
- A nice suite of examples that @rvesse approves as a path forward
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/133
I think we're all probably familiar with he semantics of `AutoCloseable`.
Examine the API note: for "... facilities... that support ... I/O-based and
non-I/O-based forms, try-with-resources b
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
I think we are getting into the realm of premature optimization at this
point. My inclination is to merge this as-is, given that we have no evidence of
real performance problems.
---
If your project
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
But since that construct goes via `HttpClientCOntext`, doesn't that take us
back to methods with `HttpContext` as a parameter? Or am I misunderstanding the
suggestion?
---
If your project is set up
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/159
Sure, but unless you object, I don't think it can hurt to be even more
specific, with some brief phrases like "The methods in this class treat all
types of Model in the same way. For behavior spe
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/159
Okay, cool, in that case maybe we can put a couple of comments into
`RdfDataMgr` to indicate that it can only ever do the "vanilla" stuff, and that
if you expect action associated with a parti
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/159
This makes sense-- one question: currently `RdfDataMgr.read(Model m, etc)`
falls through to `RdfDataMgr.read(m.getGraph(), etc)`. Should it be changed to
call `Model.read`?
---
If your project is set
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
Yeah, I can see how some kind of "moving to phase X" signaling could be
real handy. I'm not familiar enough with the query machinery to understand
where that should live, though. I think th
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
Okay, but just to be clear, that is faster by the "right" amount? In other
words, if you trigger a really really long sort and immediately abort, it
more-or-less immediately aborts?
-
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
Yeah, the fact that multiple threads are not just reading but might be
_writing_ the value really does make an `AtomicBoolean` make sense here. On the
other hand, there are no compound atomic operations
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
Yeah, the fact that multiple threads are not just reading but might be
_writing_ the value really does make an `AtomicBoolean` make sense here.
---
If your project is set up for it, you can reply
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
I have spent a lot of time thinking hard about this kind of stuff, only to
find I haven't thought as long or as hard as the folks who work on the JVMs and
compilers. {grin}
---
If your project is set
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71346429
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/AbortableComparator.java ---
@@ -0,0 +1,93 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71348900
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/AbortableComparator.java ---
@@ -0,0 +1,93 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/157
I'm not sure what the point of the periodic cancellation checking machinery
is. It seems like it is left over from your diagnostics. It doesn't seem to
save any time, because the test `count
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71347034
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/AbortableComparator.java ---
@@ -0,0 +1,93 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71170120
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71167748
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71167237
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71161082
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/157#discussion_r71160809
--- Diff:
jena-arq/src/main/java/org/apache/jena/atlas/data/SortedDataBag.java ---
@@ -69,19 +69,81 @@
protected final ThresholdPolicy policy
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@rvesse -- Does @afs 's plan to offer methods that accept
`HttpClientBuilder` meet your concerns about supporting complex authN scenarios?
---
If your project is set up for it, you can reply
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
601 - 700 of 1019 matches
Mail list logo
