On Sep 18, 2013, at 9:30 AM, Nick Williams wrote:
>
> On Sep 3, 2013, at 7:02 PM, Mandy Chung wrote:
>
>
>> So for log4j to work with security manager installed, it would have
>> torequire the application to grant certain permissions - can you confirm?
>
> Maybe one of the other Log4j guys l
On 9/20/2013 5:25 PM, Remi Forax wrote:
What you can do is to call a function that will take the stream as
argument and close the stream after its use and before returning.
R processStackStream(Function fun) {
StackStream stackStream = new
StackStream(Thread.currentThread()); // bias t
On 09/21/2013 01:58 AM, Mandy Chung wrote:
On 9/20/2013 2:46 PM, Jochen Theodorou wrote:
Exposing a StackStream API means that you need to eagerly walk the
stack
and copy the stack frames to it before it returns. I agree it is a
much
more flexible API. On the other hand, stack walking is seq
On 9/20/2013 2:46 PM, Jochen Theodorou wrote:
Exposing a StackStream API means that you need to eagerly walk the stack
and copy the stack frames to it before it returns. I agree it is a much
more flexible API. On the other hand, stack walking is sequential and
ordered and a stack stream will be
Am 20.09.2013 20:46, schrieb Mandy Chung:
[...]
I have some trouble in expressing the skipToSecondPredicate without side
effect in lambda. With the help from Paul Sandoz (thanks Paul), if I
had a stack stream, Thread.getCaller() method would be like this:
stream.filter(e -> return
REFLECTION
Am 20.09.2013 18:38, schrieb Peter Levart:
[...]
As I understand the Thread.firstCaller() does exactly that.
"findFirstCallerMatchingPredicate". Choosen name abbreviation is maybe
not making the semantic immediately obvious.
then sorry, I overlooked that in the link
though the usage of this i
Am 20.09.2013 17:45, schrieb Peter Levart:
[...]
I think the reasoning behind call-back API is that it moves the logic to
construct a suitable data structure to the Java side, skipping
intermediary representations and conversions.
StackFrameInfo is already a conversion for me. I see some value
Am 20.09.2013 20:46, schrieb Mandy Chung:
[...]
Exposing a StackStream API means that you need to eagerly walk the stack
and copy the stack frames to it before it returns. I agree it is a much
more flexible API. On the other hand, stack walking is sequential and
ordered and a stack stream will
On 9/20/13 1:58 AM, Jochen Theodorou wrote:
Am 20.09.2013 09:09, schrieb Mandy Chung:
[...]
Stack is a "stream" that allows you to walk partial stack (e.g. find
caller) or full stack trace (e.g. throwable). The filtering and mapping
operations are lazy to avoid having the VM eagerly copying the
Jochen,
On 9/20/13 4:19 AM, Jochen Theodorou wrote:
Am 20.09.2013 12:05, schrieb Peter Levart:
[...]
The use-cases described used getCallerClass(int depth) repeatedly to
find a caller by iterating over a range of depths and calling
getCallerClass(depth). You can use either Thread.walkStack or
T
On 9/20/13 2:24 AM, Peter Levart wrote:
Mandy: I like the API. It covers the use-cases optimally. I can see
how StackStreamcould be implemented with a single JNI -> Java callback
per StackFrameInfo... Why not using the same call-back principle for
Throwable API too.
One important design goa
On 09/20/2013 10:45 AM, Peter Levart wrote:
On 09/20/2013 12:56 PM, Jochen Theodorou wrote:
Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
List frames = new ArrayList<>();
Thread.walkStack(frames::add);
No so awfull.
as I said, it is unclear to me as of if walkStack walks the whole
stack o
On 09/20/2013 01:19 PM, Jochen Theodorou wrote:
that is I think a usecase for some... as I said, getCallerClass(int)
is not really ideal for us either. More ideal in this style would be
for us
public static T findCaller(Predicate predicate,
Function function)
On 09/20/2013 12:56 PM, Jochen Theodorou wrote:
Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
List frames = new ArrayList<>();
Thread.walkStack(frames::add);
No so awfull.
as I said, it is unclear to me as of if walkStack walks the whole
stack or not. Your code implies it does. If It does
On 20. September 2013 at 12:06:42, Remi Forax (fo...@univ-mlv.fr) wrote:
On 09/20/2013 11:57 AM, Jörn Huxhorn wrote:
> On 20. September 2013 at 11:35:24, Peter Levart (peter.lev...@gmail.com)
> wrote:
> On 09/20/2013 10:57 AM, Jochen Theodorou wrote:
>> Am 20.09.2013 09:28, schrieb Nick William
Am 20.09.2013 12:05, schrieb Peter Levart:
[...]
The use-cases described used getCallerClass(int depth) repeatedly to
find a caller by iterating over a range of depths and calling
getCallerClass(depth). You can use either Thread.walkStack or
Thread.firstCaller for implementing those use-cases.
Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
List frames = new ArrayList<>();
Thread.walkStack(frames::add);
No so awfull.
as I said, it is unclear to me as of if walkStack walks the whole stack
or not. Your code implies it does. If It does, I don't see the advantage
of suing a Stream he
On 09/20/2013 11:57 AM, Jörn Huxhorn wrote:
On 20. September 2013 at 11:35:24, Peter Levart (peter.lev...@gmail.com) wrote:
On 09/20/2013 10:57 AM, Jochen Theodorou wrote:
Am 20.09.2013 09:28, schrieb Nick Williams:
[...]
This is all well and good, but some of us just need a simple array.
This
On 09/20/2013 10:58 AM, Jochen Theodorou wrote:
Am 20.09.2013 09:09, schrieb Mandy Chung:
[...]
Stack is a "stream" that allows you to walk partial stack (e.g. find
caller) or full stack trace (e.g. throwable). The filtering and mapping
operations are lazy to avoid having the VM eagerly copying
On 20. September 2013 at 11:35:24, Peter Levart (peter.lev...@gmail.com) wrote:
On 09/20/2013 10:57 AM, Jochen Theodorou wrote:
> Am 20.09.2013 09:28, schrieb Nick Williams:
> [...]
>> This is all well and good, but some of us just need a simple array.
>> This seems like over-engineering. I jus
On 09/20/2013 10:57 AM, Jochen Theodorou wrote:
Am 20.09.2013 09:28, schrieb Nick Williams:
[...]
This is all well and good, but some of us just need a simple array.
This seems like over-engineering. I just want an array of
StackFrameInfos/StackTraceFrames.
if you need the full stack, then mi
On 20. September 2013 at 11:03:49, Jochen Theodorou (blackd...@gmx.org) wrote:
Am 20.09.2013 10:50, schrieb Jörn Huxhorn:
[...]
> But I have serious doubts that *this* is going to be more efficient than just
> iterating over an array.
+1
> Feel free to add all that functionality but all we a
On 09/20/2013 09:28 AM, Nick Williams wrote:
On Sep 20, 2013, at 2:09 AM, Mandy Chung wrote:
On 9/18/2013 9:22 AM, Nick Williams wrote:
Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
await responses from Mandy.
On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
Yo
Am 20.09.2013 10:50, schrieb Jörn Huxhorn:
[...]
But I have serious doubts that *this* is going to be more efficient than just
iterating over an array.
+1
Feel free to add all that functionality but all we are asking for right now is
access to the call stack array in a way that is as fast,
Am 20.09.2013 09:09, schrieb Mandy Chung:
[...]
Stack is a "stream" that allows you to walk partial stack (e.g. find
caller) or full stack trace (e.g. throwable). The filtering and mapping
operations are lazy to avoid having the VM eagerly copying the entire
stack trace data even for the short re
Am 20.09.2013 09:28, schrieb Nick Williams:
[...]
This is all well and good, but some of us just need a simple array. This seems
like over-engineering. I just want an array of StackFrameInfos/StackTraceFrames.
if you need the full stack, then misusing a Predicate and a dummy
Consumer to colle
On 20. September 2013 at 09:28:52, Nick Williams
(nicholas+open...@nicholaswilliams.net) wrote:
> This will give you an idea the API we are thinking about:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/walkstack-webrev/
Just to be clear, this means the patch I worked on for a month has been
On Sep 20, 2013, at 2:09 AM, Mandy Chung wrote:
> On 9/18/2013 9:22 AM, Nick Williams wrote:
>> Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
>> await responses from Mandy.
>>
>> On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
>>
>>> You asked at a good time. I d
On 9/18/2013 9:22 AM, Nick Williams wrote:
Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
await responses from Mandy.
On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
You asked at a good time. I discussed this with John Rose last couple days on
this topic. He ha
On Sep 18, 2013, at 11:28 AM, Mandy Chung wrote:
>
> On 9/18/2013 9:20 AM, Nick Williams wrote:
>> On Sep 9, 2013, at 4:41 PM, Mandy Chung wrote:
>>
>>> >On 9/9/13 10:02 AM, David Chase wrote:
>>Take this lightly informed suggestion with a grain of salt, but why not,
>>for purposes o
On Sep 4, 2013, at 6:23 PM, Mandy Chung wrote:
> On 9/1/2013 1:16 AM, Nick Williams wrote:
>> Class getCallerClass(): Retrieves the class of the caller of the method
>> calling getCallerClass(). This is identical to the new
>> Reflection#getCallerClass() added in Java 7u25/8.
>>
>> Class getCa
On 9/18/2013 9:20 AM, Nick Williams wrote:
On Sep 9, 2013, at 4:41 PM, Mandy Chung wrote:
>On 9/9/13 10:02 AM, David Chase wrote:
>>Take this lightly informed suggestion with a grain of salt, but why not, for
purposes of performance and security,
>>change the logging-specific getCallerClass
Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
await responses from Mandy.
On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
> On 9/17/13 10:32 AM, cowwoc wrote:
>> Hi,
>>
>>Has this been any new progress on this thread?
>> http://mail.openjdk.java.net/pipermail/
On Sep 9, 2013, at 4:41 PM, Mandy Chung wrote:
> On 9/9/13 10:02 AM, David Chase wrote:
>> Take this lightly informed suggestion with a grain of salt, but why not, for
>> purposes of performance and security,
>> change the logging-specific getCallerClass methods so that their "class"
>> referen
On Sep 9, 2013, at 12:57 PM, Peter Levart wrote:
>
> On 09/09/2013 07:02 PM, David Chase wrote:
>> Take this lightly informed suggestion with a grain of salt, but why not, for
>> purposes of performance and security,
>> change the logging-specific getCallerClass methods so that their "class"
>
On Sep 3, 2013, at 7:02 PM, Mandy Chung wrote:
> Nick,
>
> I skimmed through the changes. Congratulations for your first patch making
> changes in both hotspot and jdk code.
Thanks. And, again, apologies for my extended absence.
> In my mind, the Log4J use case accessing Class instance to ob
On 9/17/13 10:32 AM, cowwoc wrote:
Hi,
Has this been any new progress on this thread?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480
I have sent my feedback a couple weeks ago on this proposed patch but
haven't heard back from Nick.
You asked at
Hi,
Has this been any new progress on this thread?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480
I'd like to second Jörn concerns that shipping JDK8 (less than a
month to go!) without a fix would be extremely problematic. The
performance impact
On 09/09/2013 04:56 PM, Mandy Chung wrote:
On 9/9/13 10:01 AM, David M. Lloyd wrote:
I'm not sure if we can be very certain about the depth in a runtime
environment (non-debugging) unless it requires all VM implementation to
support a reliable way to return a frame at a given depth.
The stack t
On 9/9/13 10:01 AM, David M. Lloyd wrote:
I'm not sure if we can be very certain about the depth in a runtime
environment (non-debugging) unless it requires all VM implementation to
support a reliable way to return a frame at a given depth.
The stack trace is not guaranteed to contain all stack
On 9/9/13 10:02 AM, David Chase wrote:
Take this lightly informed suggestion with a grain of salt, but why not, for
purposes of performance and security,
change the logging-specific getCallerClass methods so that their "class"
references are instead wrapped in some sort of proxy object that onl
On 09/09/2013 07:02 PM, David Chase wrote:
Take this lightly informed suggestion with a grain of salt, but why not, for
purposes of performance and security,
change the logging-specific getCallerClass methods so that their "class"
references are instead wrapped in some sort of proxy object tha
After some thought the below idea seems not good. Currently j.l.Class
objects can be used to "transfer" privilige from code that can obtain
them to code that can't (like MHs for example). So doing what I proposed
would disable this ability.
Regards, Peter
Hi,
This is a good idea. It got me
Take this lightly informed suggestion with a grain of salt, but why not, for
purposes of performance and security,
change the logging-specific getCallerClass methods so that their "class"
references are instead wrapped in some sort of proxy object that only forwards
certain operations quickly wi
On 09/08/2013 09:34 PM, Mandy Chung wrote:
On 9/4/2013 6:02 PM, David M. Lloyd wrote:
This seems reasonable on the surface but falls over once you capture
the caller for more than one purpose. For example, say a logging
framework captures the caller for the purpose of supplementing log
inform
Nick,
Do you have any information to some of the questions I asked below that
can help the API discussion?
We need to decide on the permission check and also the hotspot change
has to be integrated and the jdk change will need to wait until it shows
in a promoted build. Schedule-wise, to ma
On 9/4/2013 6:02 PM, David M. Lloyd wrote:
This seems reasonable on the surface but falls over once you capture
the caller for more than one purpose. For example, say a logging
framework captures the caller for the purpose of supplementing log
information. But you call this logging framewor
On 09/04/2013 06:23 PM, Mandy Chung wrote:
On 9/1/2013 1:16 AM, Nick Williams wrote:
Class getCallerClass(): Retrieves the class of the caller of the
method calling getCallerClass(). This is identical to the new
Reflection#getCallerClass() added in Java 7u25/8.
Class getCallerClass(int): Retrie
On 9/1/2013 1:16 AM, Nick Williams wrote:
Class getCallerClass(): Retrieves the class of the caller of the method
calling getCallerClass(). This is identical to the new Reflection#getCallerClass()
added in Java 7u25/8.
Class getCallerClass(int): Retrieves the class of the caller n frames down
Just realize that I missed a few words in a sentence that could mislead
what I really mean correction below.
On 9/3/2013 5:02 PM, Mandy Chung wrote:
Nick,
I skimmed through the changes. Congratulations for your first patch
making changes in both hotspot and jdk code.
In my mind, the Lo
Nick,
I skimmed through the changes. Congratulations for your first patch
making changes in both hotspot and jdk code.
In my mind, the Log4J use case accessing Class instance to obtain
additional information for diagnosability is different than the use case
of obtaining the caller's class /
On 03/09/2013 13:24, Nick Williams wrote:
:
As regards frameworks using sun.reflect.Reflection.getCallerClass directly then
it's as I said previously, they are probably not run with a security manager
very often (at least not unless the policy is configured to allow direct access
to sun.*).
It's simple enough to just create an accessor object and add a security
check on creation. There does not need to be a significant jam-up over
this issue afaict.
On 09/03/2013 07:24 AM, Nick Williams wrote:
On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
On 02/09/2013 18:45, Nick Williams
On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
> On 02/09/2013 18:45, Nick Williams wrote:
>> :
>>
>> I didn't decide to ignore the security concerns, I just don't see any
>> security concerns. As has been /clearly/ established in the last three
>> months, frameworks have been using getCaller
On 09/03/2013 11:07 AM, Alan Bateman wrote:
On 02/09/2013 18:45, Nick Williams wrote:
:
I didn't decide to ignore the security concerns, I just don't see any
security concerns. As has been /clearly/ established in the last
three months, frameworks have been using getCallerClass for years, if
On 02/09/2013 18:45, Nick Williams wrote:
:
I didn't decide to ignore the security concerns, I just don't see any security
concerns. As has been /clearly/ established in the last three months,
frameworks have been using getCallerClass for years, if not a decade. It has
never caused a security
On 09/02/2013 06:45 PM, Nick Williams wrote:
On Sep 2, 2013, at 9:59 AM, Alan Bateman wrote:
It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So
the suggestion to start out small was to leave that out and focus on some of
the use-cases initially. I don't think this sug
On Sep 2, 2013, at 9:59 AM, Alan Bateman wrote:
> It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So
> the suggestion to start out small was to leave that out and focus on some of
> the use-cases initially. I don't think this suggestion is unreasonable as it
> allows th
On 09/02/2013 03:56 PM, Tom Hawtin wrote:
On 02/09/2013 09:33, Alan Bateman wrote:
From a quick scan then it appears that you've decided to ignore the
security concerns so I don't think anyone can (or should) sponsor this
patch until there is further discussion on the API and the security
impl
On 02/09/2013 15:08, Jörn Huxhorn wrote:
:
Nick also explained a performance issue in Thread#getStackTrace() and
Throwable#getStackTrace(). Keeping that in mind, I'm not sure if going for "start
small" (i.e. leaving that issue alone) would be a wise decision.
It was a non goal of JEP 176 to p
On 2. September 2013 at 10:33:59, Alan Bateman (alan.bate...@oracle.com) wrote:
On 01/09/2013 21:04, Nick Williams wrote:
> :
>
> So David says he thinks he can find someone at RedHat to sponsor this,
> assuming it looks good.
>
> Nick
I see the patch is accessible now.
From a quick scan t
On 02/09/2013 09:33, Alan Bateman wrote:
From a quick scan then it appears that you've decided to ignore the
security concerns so I don't think anyone can (or should) sponsor this
patch until there is further discussion on the API and the security
implications.
I've barely looked through the
On 01/09/2013 21:04, Nick Williams wrote:
:
So David says he thinks he can find someone at RedHat to sponsor this, assuming
it looks good.
Nick
I see the patch is accessible now.
From a quick scan then it appears that you've decided to ignore the
security concerns so I don't think anyone ca
Thanks for the help, everyone! The Qualys SSL Labs tool was invaluable.
Apparently using "-SSLv3" in the SSLCipherSuite setting in Apache also disables
TLSv1.0 and TLSv1.2, breaking most clients. Not very intuitive, but I got it
sorted out so that I'm supporting only TLSv1.0 through TLSv1.2, whi
On 09/01/2013 09:50 AM, Nick Williams wrote:
> Interesting. I can access HTTPS in all of my browsers. OT, to help my
> figure out what's up with my HTTPS, what browsers and versions are
> y'all using, Jörn and Alan?
I get the same problems with Firefox 23 on Linux. This will help you
debug som
As Jörn pointed out, you can also use HTTP. Could you tell me which
browser/version you're using? I'd love to figure out what's up with my HTTPS. I
can access it in all my browsers.
I understand your point about making CallerSensitive public being a non-goal of
JEP 176. But, if we're going to m
Interesting. I can access HTTPS in all of my browsers. OT, to help my figure
out what's up with my HTTPS, what browsers and versions are y'all using, Jörn
and Alan?
N
On Sep 1, 2013, at 10:40 AM, Jörn Huxhorn wrote:
> This looks pretty awesome!
>
> There are just two small things I'd suggest:
This looks pretty awesome!
There are just two small things I'd suggest:
Rename
StackTraceFrame[] getCurrentStackTrace()
to
StackTraceFrame[] getStackFrames() (I'd prefer this one…)
or
StackTraceFrame[] getStackTraceFrames() (…while this one is probably more
accurate.)
or
StackTraceFrame[] getCur
On 01/09/2013 09:16, Nick Williams wrote:
:
I believe I have followed all of the procedures as closely as possible. I await
feedback and hope for some support on this, so that we can get a public
replacement for this method in Java 8. Let me know if you have any questions.
You may need to che
I have completed and am proposing a patch for replacing
sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw
no point in duplicating an issue, even though it's over 10 years old, so I'm
indicating that this is a patch for 4851444
(http://bugs.sun.com/bugdatabase/view_bu
70 matches
Mail list logo