le Jetty
webserver and will use Apache's HttpClient to talk to it.
Uwe
-Original Message-
From: Uwe Schindler
Sent: Friday, July 13, 2018 11:59 AM
To: 'Alan Bateman' ; 'Rory O'Donnell'
Subject: RE: FW: [JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+21) -
Bui
On 18/10/2016 13:34, Uwe Schindler wrote:
Hi,
Thanks Alan for the clarification and the documentation fixes! This does not solve the
"returns null if not found or otherwise denied" issue, but this is a problem
from the early Java days, which cannot be fixed anymore (to throw useful Exception
On 18/10/2016 10:25, Uwe Schindler wrote:
:
From my perspective this looks wrong, because there is no security
implications documented on Class#getResource, so it is completely unclear that
you actually need a doPrivileged when calling Class#getResource[AsStream]().
This is a separate issue
On 17/10/2016 13:16, Uwe Schindler wrote:
Hi,
yes I checked more already: The issue is caused by the mentioned change
(canonicalize of FilePermission). According to the docs of SecurityManager and
FilePermission, code should always be able to read stuff below the classpath
where the code was
On 21/05/2016 13:51, Robert Muir wrote:
:
Just a little followup: It seems most code impacted by this change is
just using jaxb's base64 class. We've seen it not just with Solr but
with cloud libraries like AWS SDK and so on.
I'm not really suggesting anything here but just mentioning it as a
On 16/05/2016 16:19, Uwe Schindler wrote:
Thanks Alan,
so this means we should better remove the references to the mentioned class
from the Apache Solr code if not needed (I don't think we need the Java EE
features here, it might be an oversight). I just wonder why Javac succeeded in
our ca
On 16/05/2016 15:28, Uwe Schindler wrote:
:
This is not the only class that’s missing at runtime, there are more: I do not have the
complete list, but our checks using the forbiddenapis Ant/Maven/Gradle plugin fails to
load classes around JAXB/XML (javax.xml.bind.*, javax.jws.*) and CORBA (org
On 26/03/2016 23:16, Uwe Schindler wrote:
:
Now all analysis tests pass, also the small test program posted
previously:
$ java -Djava.security.manager Test
class sun.util.locale.provider.DictionaryBasedBreakIterator
FYI: Lucene runs all tests with a security manager to enforce some
restric
On 26/03/2016 19:11, Uwe Schindler wrote:
Hi Alan, hi Robert, Hi Lucene developers,
I was able to reproduce the bug in isolation. The reason why Robert and you did
not see it was quite simple:
- You need to enable a security manager
- You need to list all locales before
Thanks, that's enough
On 13/05/2015 10:27, Uwe Schindler wrote:
:
There is one additional issue we found recently on MacOSX, but this is
only slightly related to the one here. It looks like on MacOSX,
FileChannel#force is mostly a noop regarding syncing data to disk,
because the underlying operating system requi
On 16/05/2015 18:26, Robert Muir wrote:
:
Code that is responsible for synchronizing data to disk is really
important, its the last place you want this kind of complexity :(
Yes, we know this. Let's try to come up with a solution for this in the
coming weeks.
-Alan.
-
On 16/05/2015 17:48, Robert Muir wrote:
:
Separately, the addition of an explicit api for this is a fantastic
idea, but its no solution for users on the existing api.
JDK 9 is not planned to ship until 2016 so if there is a new API then I
would hope this is time enough for Lucene to add supp
On 12/05/2015 19:59, Uwe Schindler wrote:
Hallo Alan,
I just wanted to come back to this issue, because there was no further communication
recently regarding the behavior of Java 9 with opening a FileChannel on a directory to
fsync the directory metadata. Unfortunately, this would break the im
13 matches
Mail list logo
