Thanks for your reviews!
-Sundar
On 27/10/17, 3:01 AM, mandy chung wrote:
On 10/26/17 10:04 AM, Sundararajan Athijegannathan wrote:
Updated webrev:
http://cr.openjdk.java.net/~sundar/8189777/webrev.04/index.html
Looks good. Thanks for incorporating the comments.
Mandy
On 26 October 2017 at 23:35, Cédric Champeau wrote:
> There's a good argument for 1, though. log4j typically doesn't separate api
> and implementation. So a module would "require 'log4j'". It means that if
> another module like slf4j doesn't "pretend to be" log4j, it's now going to
> fail. Said di
There's a good argument for 1, though. log4j typically doesn't separate api
and implementation. So a module would "require 'log4j'". It means that if
another module like slf4j doesn't "pretend to be" log4j, it's now going to
fail. Said differently, Jigsaw kills module replacements and fatjars.
201
Thanks Alex and David, those are good arguments. So option 2 it is.
Stephen
On 26 October 2017 at 23:05, David Lloyd wrote:
> On Thu, Oct 26, 2017 at 3:03 PM, Stephen Colebourne
> wrote:
>> For most service providers, option 2 is obvious, however for logging
>> it is generally the case that only
I’d like to reverse this dependency to be that in the end, I want every module
in the app I construct to funnel through and use a single Logging
implementation so that I can linearize the logging streams into a single stream
of details that help me to understand the health and progress of my
ap
On Thu, Oct 26, 2017 at 3:03 PM, Stephen Colebourne
wrote:
> For most service providers, option 2 is obvious, however for logging
> it is generally the case that only one implementation should be
> present. If all the jar files that implement a specific logging API
> had the same module name (opti
On 10/26/17 10:04 AM, Sundararajan Athijegannathan wrote:
Updated webrev:
http://cr.openjdk.java.net/~sundar/8189777/webrev.04/index.html
Looks good. Thanks for incorporating the comments.
Mandy
On 10/26/2017 1:03 PM, Stephen Colebourne wrote:
(previously posted on core-libs-dev, moved by request)
(Thanks!)
Option 1:
All modules that implement a particular logging API must have the same
module name
eg. every module that implements "org.slf4j" (the API) must be named
"org.slf4j.impl"
On 26/10/2017 18:04, Sundararajan Athijegannathan wrote:
Updated webrev:
http://cr.openjdk.java.net/~sundar/8189777/webrev.04/index.html
This is much cleaner and addresses the points that I brought up. So
looks good to me.
-Alan
(previously posted on core-libs-dev, moved by request)
I've spent some time discussing module names for logging
implementations recently:
https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs
https://issues.apache.org/jira/browse/LOG4J2-2056
https://jira.qos.ch/browse/SLF4J-407?jql=te
Updated webrev:
http://cr.openjdk.java.net/~sundar/8189777/webrev.04/index.html
-Sundar
On 26/10/17, 10:17 PM, mandy chung wrote:
jlink --add-modules ALL-MODULE-PATH does not work in this patch since
the default module is added after the roots set is computed.
AppRuntimeImageBuilder could ca
jlink --add-modules ALL-MODULE-PATH does not work in this patch since
the default module is added after the roots set is computed.
AppRuntimeImageBuilder could calls its moduleFinder method (that calls
JlinkTask::newModuleFinder). packager may already provide the default
module path and we w
>From within Java (i.e. for the current VM) you could simply do:
ClassLoader.getSystemResourceAsStream("java/io/InputStream.class")
Regards,
Volker
On Tue, Oct 24, 2017 at 3:47 AM, Sundararajan Athijegannathan
wrote:
> A simple nashorn sample to extract single .class using jrt file system
> pr
13 matches
Mail list logo
