On 09/11/2014 06:17 PM, Daniel Fuchs wrote:
On 9/10/14 1:25 PM, Alan Bateman wrote:
On 10/09/2014 10:49, Daniel Fuchs wrote:
Hi,
Please find below a proposed patch for
8043306 - Provide a replacement for the API that allowed to listen
for LogManager configuration changes
https://bug
Hello,
Just a note, acc is going to leak the context class loader until the
listener is removed. That should be noted in the documentation.
Also if there is a runtime exception during run() of a listener it will
block any other listeners to be invoked and the exception is going to be
propagated p
On 11/09/2014 17:33, Vladimir Ivanov wrote:
Looks ok.
I don't like the idea of having 2 copies of WB API for hotspot and jdk.
But that's tolerable unless we have shared location for test libraries
in top repository. Having reliable tests is more important IMO.
Has there been any thought put in
On 12/09/2014 05:57, huizhe wang wrote:
I see. So you're looking for a sponsor. Unfortunately, I personally
don't have circles. It would be great if you could find a sponsor.
JAXP sources came from Apache that still supports JDK 1.4. A very
large amount of code therefore are obsolete with reg
On 11/09/14 14:39, Alan Bateman wrote:
On 11/09/2014 12:20, Miroslav Kos wrote:
Hello,
please review following change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8054548
webrev: http://cr.openjdk.java.net/~mkos/8054548/jaxws.00/
It is basically replacing obsolete code using core reflection b
Hi Stanimir,
On 9/12/14 9:47 AM, Stanimir Simeonoff wrote:
Hello,
Just a note, acc is going to leak the context class loader until the
listener is removed. That should be noted in the documentation.
Good point. But I expect the concrete listener class will also be
usually loaded by the conte
Hi Peter,
On 9/12/14 8:26 AM, Peter Levart wrote:
Oh yes. I put it there just to avoid it being flagged by
NetBeans:
'equals() method not checking type of its parameters'
I guess it would be better to just return this == other;
(which unfortunately doesn't remove the warning)
What about usin
Hi Peter,
On 9/12/14 9:14 AM, Peter Levart wrote:
> Wouldn't it be cleaner to evaluate SM presence in the lambda wrapper
> which would always be constructed, like that:
>
Well - then we would always be storing the ACC, so
maybe we could just always call
AccessController.doPrivileged, whether the
On 12/09/2014 08:14, Peter Levart wrote:
:
Just a question about security and delayed execution...
If at the time the configuration listener is added to the LogManager,
SecurityManager is not set, the listener will be invoked directly even
if at time the listener is invoked, SM has been set.
>
> Good point. But I expect the concrete listener class will also be usually
> loaded by the context class loader - so isn't that kind of expected anyway?
> I didn't want to stuff too many implementation details into the spec.
> Maybe that could be an API note however.
> Would anyone be able to su
@Alan
Yes, I would like help the jaxp in openjdk project.
But I thought that were different projects, but how are the same.
I believe will the same process.
So I will waiting to a sponsor.
@huizhe
Yes, I see the code is a little deprecated, I will try improve it as I can.
On Fri, Sep 12, 2014 at
On 12/09/2014 09:39, Miroslav Kos wrote:
I agree that the code looks scary, but it's because we have to support
range of jdk (currently jdk6 to jdk9) and we want to avoid maintaining
several branches. The standalone project must work even with jdk6. The
magic here is to make the latest JAX-WS w
On 12/09/2014 10:40, Otávio Gonçalves de Santana wrote:
@Alan
Yes, I would like help the jaxp in openjdk project.
But I thought that were different projects, but how are the same.
I believe will the same process.
So I will waiting to a sponsor.
I understand it can be a bit confusing. In summary,
Paul,
thanks for your review. I'll take care about this change, since
Konstantin is on vacation.
updated webrev:
http://cr.openjdk.java.net/~iignatyev/kshefov/8057719/webrev.00/
please see inline answers.
Igor
On 09/11/2014 05:12 PM, Paul Sandoz wrote:
On Sep 5, 2014, at 7:52 PM, Konsta
Thanks Stanimir,
On 9/12/14 11:24 AM, Stanimir Simeonoff wrote:
On leaks. The c-tor of LogManager leaks the thread group and the current
AccessControlContext till JVM shutdown. The constructor code should be
something like the one below with Cleaner getting ThreadGroup in its
c-tor as well.
On 12/09/14 11:51, Alan Bateman wrote:
On 12/09/2014 09:39, Miroslav Kos wrote:
I agree that the code looks scary, but it's because we have to
support range of jdk (currently jdk6 to jdk9) and we want to avoid
maintaining several branches. The standalone project must work even
with jdk6. The
I haven't acess to cr.openjdk.java.net yet.
But I uploaded another way.
https://dl.dropboxusercontent.com/u/16109193/open_jdk/jaxp/string_buffer_2_string_builder/index.html
On Fri, Sep 12, 2014 at 7:02 AM, Alan Bateman
wrote:
> On 12/09/2014 10:40, Otávio Gonçalves de Santana wrote:
>
>> @Alan
On 12/09/2014 11:51, Miroslav Kos wrote:
If you are ok with it, I would proceed with this change as it is for
now and improved generated classes would go into jdk9 with next
regular sync integration.
Yes, I'm okay with this. I do expect that additional changes will be
needed later but we'll c
On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
However the listeners are to be invoked in the same order they have been
added.
I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were using HashMap to store listeners,
and ther
On 09/12/2014 11:21 AM, Alan Bateman wrote:
On 12/09/2014 08:14, Peter Levart wrote:
:
Just a question about security and delayed execution...
If at the time the configuration listener is added to the LogManager,
SecurityManager is not set, the listener will be invoked directly
even if at ti
Hi Peter,
I like the LHM (personal favorite data structure) approach with the
dual-purpose key.
Stanimir
On Fri, Sep 12, 2014 at 2:55 PM, Peter Levart
wrote:
> On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
>
>> However the listeners are to be invoked in the same order they have been
>>> added.
>>
On 12/09/2014 11:45, Daniel Fuchs wrote:
I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were using HashMap to store listeners,
and therefore the order in which listeners were invoked was also
undefined. Nobody has ever
On 9/12/14 1:55 PM, Peter Levart wrote:
On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
However the listeners are to be invoked in the same order they have been
added.
I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were u
Hi,
On Sep 12, 2014, at 12:45 PM, Igor Ignatyev wrote:
> Paul,
>
> thanks for your review. I'll take care about this change, since Konstantin is
> on vacation.
>
Thanks.
> updated webrev:
> http://cr.openjdk.java.net/~iignatyev/kshefov/8057719/webrev.00/
>
> please see inline answers.
>
On 9/12/14 2:37 PM, Alan Bateman wrote:
On 12/09/2014 11:45, Daniel Fuchs wrote:
I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were using HashMap to store listeners,
and therefore the order in which listeners were inv
Alan,
I wasn't aware about such capability. Sounds interesting.
Since we are short on time integrating tests for JEP210 into 9 and 8u40,
I'd suggest to remove dependency on WB API from the tests for now and
file a followup bug to restore it once a suitable solution is found. As
I understand,
On 12/09/2014 14:38, Daniel Fuchs wrote:
Would modifying the specification of addConfigurationListener()
as follows be sufficient to make the workings of the proposed
implementation clearer?
/**
* Adds a configuration listener to be invoked each time the logging
* properties are r
Thanks Alan!
I have updated the webrev with your suggestions:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
-- daniel
On 9/12/14 3:54 PM, Alan Bateman wrote:
On 12/09/2014 14:38, Daniel Fuchs wrote:
Would modifying the specification of addConfigurationListener()
as follows be
On 12/09/2014 15:16, Daniel Fuchs wrote:
Thanks Alan!
I have updated the webrev with your suggestions:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
-- daniel
A minor suggestion for readConfiguration is that "Any register
configuration listeners .." might be a bit better than
On 9/12/14 4:42 PM, Alan Bateman wrote:
On 12/09/2014 15:16, Daniel Fuchs wrote:
Thanks Alan!
I have updated the webrev with your suggestions:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
-- daniel
A minor suggestion for readConfiguration is that "Any register
configuration
Vladimir/Alan,
Yes, only WB.fullGC() is needed, I replaced it w/ System.gc() and
removed whitebox from the changes.
updated webrev :
http://cr.openjdk.java.net/~iignatyev/kshefov/8057707/webrev.00/
Thanks
Igor
On 09/12/2014 05:41 PM, Vladimir Ivanov wrote:
Alan,
I wasn't aware about such
Looks good.
Best regards,
Vladimir Ivanov
On 9/12/14, 7:03 PM, Igor Ignatyev wrote:
Vladimir/Alan,
Yes, only WB.fullGC() is needed, I replaced it w/ System.gc() and
removed whitebox from the changes.
updated webrev :
http://cr.openjdk.java.net/~iignatyev/kshefov/8057707/webrev.00/
Thanks
Igo
Daniel,
I suppose that the propagating uncaught exceptions to the caller was the
previous behavior of the old property change methods but it seems out of place
for the LogManager. The LogManager is a global resource so broken listener
code in web app A could suppress notifications in web app
Hi Alan, Otavio,
I'm very delighted that Otavio wants to help! I'm totally fine with
updating the source to a higher source level, though diverging from the
upstream projects in the process. I was only saying that it's currently
not a high priority for me and that I don't have circles. There's
On 9/12/14 5:39 PM, Jason Mehrens wrote:
Daniel,
I suppose that the propagating uncaught exceptions to the caller was the
previous behavior of the old property change methods but it seems out of place
for the LogManager. The LogManager is a global resource so broken listener
code in web app
Daniel,
Agreed. My preference would be to:
1. Catch and report them to 'System.err'. That type of code happens in the
LogManager and exceptions in this case are not the normal condition.
2. Don't specify how uncaught exceptions are handled in the javadocs.
3. Outside of this issue, make an
Hi,
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/267950e85a3b
The above changeset for this fix apparently broke the images build.
ERROR: Failed module access verification
CheckModules.gmk:38: recipe for target 'checkdeps' failed
make[3]: Leaving directory '/opt/jprt/T/P1/173827.xxx/s/make'
Main.
On 9/12/14 12:21 PM, Phil Race wrote:
Hi,
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/267950e85a3b
The above changeset for this fix apparently broke the images build.
ERROR: Failed module access verification
CheckModules.gmk:38: recipe for target 'checkdeps' failed
make[3]: Leaving directory '
Hello,
I created a formal webrev:
Issue: https://bugs.openjdk.java.net/browse/JDK-8057793
Webrev: http://cr.openjdk.java.net/~bpb/8057793/webrev.00/
Based on manual inspection of the revised code the patch looks good to me. The
test submitted with the issue now succeeds as do all regression te
39 matches
Mail list logo
