On 01/07/16 16:33, Mandy Chung wrote:
I think the additional check is unecessary but it’s harmless if you prefre to
keep that.
Oh - I see - the permission check in ConfigurationData::merge
can be removed: ConfigurationData is a private class and
config is a private field. I will do that.
chee
> On Jul 1, 2016, at 8:23 AM, Daniel Fuchs wrote:
>
> On 01/07/16 16:19, Mandy Chung wrote:
>>> I'd prefer to keep the doPrivileged in LogManager so that
>>> > Logger.mergeWithSystemLogger can call checkpermission().
>>> >
>>> > From a conceptual point of view it's only when calling
>>> > this m
On 01/07/16 16:19, Mandy Chung wrote:
I'd prefer to keep the doPrivileged in LogManager so that
> Logger.mergeWithSystemLogger can call checkpermission().
>
> From a conceptual point of view it's only when calling
> this method from LogManager that we want to be privileged,
> even though the meth
> On Jul 1, 2016, at 8:16 AM, Daniel Fuchs wrote:
>
> On 01/07/16 16:09, Mandy Chung wrote:
>> I was thinking to move the entire doPrivileged block to
>> mergeWithSystemLogger that will look like:
>>
>>if (cfg == system.config) {
>>return;
>>}
>>
>>// sanity check
>>if
On 01/07/16 16:09, Mandy Chung wrote:
I was thinking to move the entire doPrivileged block to mergeWithSystemLogger
that will look like:
if (cfg == system.config) {
return;
}
// sanity check
if (!system.isSystemLogger ….
throw new InternalError(…);
final Co
> On Jul 1, 2016, at 7:09 AM, Daniel Fuchs wrote:
>
>
> OK. I was concerned about the cost of creating a doPrivileged call
> for nothing - but then reflected that system classes usually call
> getLogger only once for a specific logger - at which point the
> doPrivileged will be needed anyway (o
Hi Mandy,
On 30/06/16 19:23, Mandy Chung wrote:
Looks pretty good. What if the application logger is a custom Logger subclass?
Would this mechanism support that?
Yes - this is taken into account, but there are
limitations: by design only data that has been set by
calling the super class sett
> On Jun 30, 2016, at 9:33 AM, Daniel Fuchs wrote:
>
> Indeed, good catch! I should have seen that :-(
>
> Here is a patch that should take care of the issue:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8159245/webrev.05
>
> Thanks for your offline suggestions on how to deal with that
> sce
Hi Mandy,
On 21/06/16 17:01, Mandy Chung wrote:
On Jun 21, 2016, at 8:39 AM, Daniel Fuchs wrote:
I don't understand this scenario.
ConfigurationData should remain as simple as possible.
Logger.getLogger() / LogManager.demandSystemLogger() will never return
a logger before it has been configu
Hi Daniel,
Got you point.
Thank you
-Hamlin
On 2016/6/22 13:24, Daniel Fuchs wrote:
Hi Hamlin,
On 22/06/16 02:40, Hamlin Li wrote:
Just another minor comment, I'm not sure if following line is necessary
in Logger.java, as it's already been checked in LogManager.java line
577:
439 if (cfg
Hi Hamlin,
On 22/06/16 02:40, Hamlin Li wrote:
Just another minor comment, I'm not sure if following line is necessary
in Logger.java, as it's already been checked in LogManager.java line 577:
439 if (cfg == other) return cfg;
Yes, you're right - but it makes sense for the method to have it :
Hi Daniel,
Thank you for detailed explanation, new version makes sense to me.
Just another minor comment, I'm not sure if following line is necessary
in Logger.java, as it's already been checked in LogManager.java line 577:
439 if (cfg == other) return cfg;
Thank you
-Hamlin
On 2016/6/21 19:
On 21/06/16 17:01, Mandy Chung wrote:
On Jun 21, 2016, at 8:39 AM, Daniel Fuchs wrote:
I don't understand this scenario.
ConfigurationData should remain as simple as possible.
Logger.getLogger() / LogManager.demandSystemLogger() will never return
a logger before it has been configured.
When w
> On Jun 21, 2016, at 8:39 AM, Daniel Fuchs wrote:
>
> I don't understand this scenario.
> ConfigurationData should remain as simple as possible.
> Logger.getLogger() / LogManager.demandSystemLogger() will never return
> a logger before it has been configured.
> When we're merging the configurat
On 21/06/16 16:12, Mandy Chung wrote:
On Jun 21, 2016, at 4:54 AM, Daniel Fuchs wrote:
Hi Hamlin,
I was mistaken in my first assessment.
The case where the system handler's list is not empty
should only happen if by misfortune two different threads
happen to attempt to merge the same two co
> On Jun 21, 2016, at 4:54 AM, Daniel Fuchs wrote:
>
> Hi Hamlin,
>
> I was mistaken in my first assessment.
>
> The case where the system handler's list is not empty
> should only happen if by misfortune two different threads
> happen to attempt to merge the same two configurations
> concurre
Hi Hamlin,
I was mistaken in my first assessment.
The case where the system handler's list is not empty
should only happen if by misfortune two different threads
happen to attempt to merge the same two configurations
concurrently. Though of no consequence for level, filter,
etc... (single values
On 21/06/16 04:29, Hamlin Li wrote:
Hi Daniel,
I just has one simple question.
In new version, in Logger::importConfig, userParentHandlers, filter,
levelObject are copied from other(ConfigurationData) unconditionally,
handlers in other are only *copied *when it's empty in system.
In previous ver
Hi Daniel,
I just has one simple question.
In new version, in Logger::importConfig, userParentHandlers, filter,
levelObject are copied from other(ConfigurationData) unconditionally,
handlers in other are only *copied *when it's empty in system.
In previous version, handlers in other are *added
Hi,
Please find below a patch for:
8159245: Loggers created by system classes are not initialized
correctly when configured programmatically from
application code.
Issue:
https://bugs.openjdk.java.net/browse/JDK-8150173
Patch:
http://cr.openjdk.java.net/~dfuchs/webrev_8159245
20 matches
Mail list logo