Hi,
I have pushed an implementation of the prototype
in the sandbox.
The branch name is JDK-8046565-branch
Instructions for cloning a sandbox branch can be found here:
http://cr.openjdk.java.net/~chegar/docs/sandbox.html
best regards,
-- daniel
On 05/10/15 12:54, Daniel Fuchs wrote:
New
On 10/05/2015 09:59 PM, Daniel Fuchs wrote:
Thanks Roger!
I have updated the specdiff online.
http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html
The only comment I haven't taken into account yet is this:
> - the LoggerFinder constructor says "Only
Hi,
This case does not require a restriction. This is not really a case of
a singleton object.
I think the statement is a statement of fact.
The behavior should be attributed to the LoggerFinder.getLoggerFinder method
and not to the constructor of LoggerFinder.
Roger
On 10/6/2015 9:32 AM,
New JEP Candidate: http://openjdk.java.net/jeps/264
Hi I have uploaded an initial prototype specdiff:
http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html
LoggerFinder methods that take a Class caller argument
will take a java.lang.reflect.Module callerModule
Hi Daniel,
This looks good, a few comments...
j.l.System:
- the behaviors described by the @implNote in getLogger(name) and
@implSpec in getLogger(name, resourceBundle) seem like they should
be consistent
for the two methods.
System.Logger:
- log(level, throwable, Supplier) - to
You are correct that the discussion on the serviceLoader may be off-topic wrt
JEP 264. I believe I mentioned that currently Log4j only supports binding with
a single implementation as well. But we don’t take the first, we take the one
with the highest priority.
Ralph
> On Sep 30, 2015, at
On 09/29/2015 11:17 PM, Ralph Goers wrote:
FWIW, I considered using the ServiceLoader to bind the Log4j API to the
implementation. However, Log4j also includes the API version and only looks for
bindings that implement that version. We also include a “priority” - the
binding with the
On 30/09/2015 14:59, Ralph Goers wrote:
If I understand you correctly, then no that isn’t what I would want. The
version and priority are captured in the same properties file where the class
name is specified. If the class implements the wrong version or isn’t chosen
due to its priority then
Alan,
Your suggestion is literally the same thing that Peter suggested which is what
my reply below was to. So you can take that reply as the reply to your message
as well.
What would be preferable is to have the serviceLoader accept “criteria” (which
are callbacks) that can evaluate each of
Hi Ralph,
On 30/09/15 18:30, Ralph Goers wrote:
What would be preferable is to have the serviceLoader accept “criteria” (which are
callbacks) that can evaluate each of the located services based on any additional
properties that are included in the properties file and either eliminate them or
FWIW, I considered using the ServiceLoader to bind the Log4j API to the
implementation. However, Log4j also includes the API version and only looks for
bindings that implement that version. We also include a “priority” - the
binding with the highest priority wins - at the moment. At some future
On 20/09/15 15:46, Peter Levart wrote:
On 09/18/2015 06:17 PM, mark.reinh...@oracle.com wrote:
New JEP Candidate:http://openjdk.java.net/jeps/264
- Mark
Hi,
What is the purpose of exposing a factory for loggers in the generally
exported package (java.lang) and making it standard Java API
Hi Ralph,
On 20/09/15 07:54, Ralph Goers wrote:
I do have some questions on this.
Would anyone realistically be able to use SLF4J/Logback or Log4j 2 as the
implementation? The logging implementation needs to be able to configure
itself before logging can realistically be performed. If
On 09/18/2015 06:17 PM, mark.reinh...@oracle.com wrote:
New JEP Candidate: http://openjdk.java.net/jeps/264
- Mark
Hi,
What is the purpose of exposing a factory for loggers in the generally
exported package (java.lang) and making it standard Java API as opposed
to keeping it internal API
I do have some questions on this.
Would anyone realistically be able to use SLF4J/Logback or Log4j 2 as the
implementation? The logging implementation needs to be able to configure
itself before logging can realistically be performed. If logging initialization
happens too soon the
On 09/18/2015 11:17 AM, mark.reinh...@oracle.com wrote:
New JEP Candidate: http://openjdk.java.net/jeps/264
+1 good idea!
--
- DML
16 matches
Mail list logo
